Mac Magazin/MacEasy 8/Mac Magazin and MacEasy Magazine CD - Issue 08.iso/Sharewarebibliothek/DFÜ/mackermit199(190) folder/cku-kermit.doc

Text File | 1992-12-08 | 251KB | 5,881 lines

                              C-KERMIT USER GUIDE


              FOR UNIX, VAX/VMS, AND SOME OTHER OPERATING SYSTEMS



                             Version 5A(180) BETA





                    Christine M. Gianone and Frank da Cruz

              Columbia University Center for Computing Activities
                             612 West 115th Street
                            New York, NY 10025 USA





                                   D*R*A*F*T

                                  26 May 1992









                           Copyright (C) 1985, 1992
            Trustees of Columbia University in the City of New York

      Permission is granted to any individual or institution to use this
 software as long as it is not sold for profit.  This copyright notice must be
  retained.  This software may not be included in commercial products without
                  written permission of Columbia University.
1. C-Kermit

********
This document is formatted as an ordinary, plain text ASCII disk file.  Typeset
copies are available from Columbia University.  Changes should be made to
CKUKER.MSS.
********

Program:        Frank da Cruz (Columbia University), contributions by many
                others.
Language:       C
Documentation:  Christine Gianone, Frank da Cruz (Columbia University).
Version:        5A(180) BETA
Date:           May 26, 1992


C-Kermit Capabilities At A Glance:

  Local operation:                   Yes
  Remote operation:                  Yes
  Transfer text files:               Yes
  Transfer binary files:             Yes
  International text:                Yes
  Wildcard send:                     Yes
  File transfer interruption:        Yes
  Filename collision actions:        Yes
  Can time out:                      Yes
  8th-bit prefixing:                 Yes
  Repeat count prefixing:            Yes
  Alternate block checks:            Yes
  Automatic parity detection:        Yes
  Dynamic packet length:             Yes
  CONNECT mode:                      Yes
  Terminal emulation:                Depends on implementation
  Key mapping:                       Yes
  Communication settings:            Yes
  Transmit BREAK:                    Yes (most versions)
  Support for dialout modems:        Yes
  TCP/IP support:                    Yes (some versions, Berkeley sockets)
  X.25 support:                      Yes (SUN versions with SunLink)
  IBM mainframe communication:       Yes
  Transaction logging:               Yes
  Session logging:                   Yes
  Debug logging:                     Yes
  Packet logging:                    Yes
  Act as server:                     Yes
  Talk to server:                    Yes
  Advanced server functions:         Yes
  Security for server:               Yes
  Local file management:             Yes
  Command/Init files:                Yes
  Long packets:                      Yes
  Sliding Windows:                   Yes
  File attributes packets:           Yes
  Command macros:                    Yes
  Script programming language:       Yes
  Raw file transmit and capture:     Yes

    -----------------------------------------------------------------------
    IMPORTANT NOTICE: The user manual for the current release of C-Kermit
    is "Using C-Kermit", by Frank da Cruz and Christine M. Gianone, published
    by Digital Press, Burlington, MA.  Publication date: Fall 1992.  After
    Fall 1992, call Digital Press at 1-800-344-4825 for further
    information.
    -----------------------------------------------------------------------

1.1. Acknowledgements

Thanks to the dozens of people who have been involved in C-Kermit development
over the years, especially Bill Catchings, Jeff Damens and Chris Maio (formerly
of Columbia University), and Herm Fischer of Encino, CA, for their roles in its
initial development.  And special thanks to those who put so much work into
features or testing of version 5A:

    Kristoffer Eriksson (Peridot Konsult AB, Orebro, Sweden)
    Bo Kullmar (Sveriges Riksbank (Central Bank of Sweden), Stockholm)
    Tor Lillqvist (Helsinki University, Finland)
    Warren H. Tucker (Tridom Corporation, Mountain Park, Georgia, USA)
    Peter Mauzey (AT&T Bell Laboratories, Middletown, New Jersey, USA)
    Terry Kennedy (St Peters College, Jersey City, NJ, USA)
    Chuck Hedrick (Rutgers University, New Brunswick, NJ, USA)
    Joe R. Doupnik (Utah State University, USA)
    Hirofumi Fujii (Japan National Lab for High Energy Physics, Tokyo)
    Ken Yap (University of Rochester, New York, USA)
    Marcello Frutig (Catholic University, Rio de Janeiro, Brazil)
    Paul Placeway (BBN, Cambridge, Massachusetts, USA)
    Mark Buda (Digital Equipment Corporation, New Hampshire, USA)
    William Bader (Software Consulting Services, Nazareth, PA, USA)
    Steve Walton (California State University Northridge, USA)
    Rick Watson (University of Texas at Austin, USA)
    Peter Svanberg (Royal Techn. HS, Sweden)
    Michel Robitaille (University of Montreal, Canada)
    Kai Uwe Rommel (Technische Universitat Muenchen, Germany)
    Paul Kline (Drake University, USA)
    Chris Adie (Edinburgh University, Scotland, UK)
    Chris Armstrong (Brookhaven National Laboratory, New York, USA)
    James Harvey (Indiana/Purdue University, USA)
    Bob Larson (University of Southern California, USA)
    Christian Hemsing (RWTH Aachen, Germany)
    Bruce J. Moore (Allen-Bradley Co, Highland Heights, OH)

Kristoffer, Bo, Warren, and Peter comprised the "modem committee", which worked
long and hard to rationalize C-Kermit's treatment of modem signals in the many
and varied UNIX environments.  Kristoffer and Bo also contributed much code to
the UNIX-specific support modules.  Kristoffer deserves a special Archaeology
Achievement Award for a detailed study and unraveling of many years' accretions
of incomprehensible "magic" in the infamous ckutio.c module (a collection of
supposedly simple functions that give the emphatic lie to all claims that UNIX
is a "portable operating system").

Ken got the TCP/IP support started by supplying the socket-opening code for the
Berkeley UNIX version.  Marcello supplied the SunLink X.25 code.  Paul
Placeway, Rick Watson, Peter Svanberg, Paul Kline, and Michel Robitaille
contributed enormously to the Macintosh version (and continue to do so).  The
two Chris's, and more recently Kai-Uwe, for the OS/2 version; Terry, William,
James, Mark for the VAX/VMS version; Steve for the Amiga version; Christian for
the OS-9 version; Bruce for the Atari ST version.

Chuck found and fixed many bugs and contributed many valuable insights, as well
as writing the UNIX "man page" for C-Kermit 5A.

And thanks to the indefatigable and omniscient Joe Doupnik (author of MS-DOS
Kermit), who worked closely with the authors on the design of the sliding
window algorithms, the script programming language, and the international
character set support during the joint development effort for MS-DOS Kermit 3.0
and C-Kermit 5A (and in his spare time, Joe lent a hand with the AT&T 7300 UNIX
PC version of C-Kermit).  And finally, thanks to the dozens (hundreds) of
others who tested C-Kermit on dozens (hundreds) of hardware and software
platforms and contributed bug reports, fixes, new features, and suggestions:

   Chris Adie, Edinburgh U, Scotland (OS/2 support)
   Robert Adsett, University of Waterloo, Canada
   Larry Afrin, Clemson U
   Barry Archer, U of Missouri
   Robert Andersson, International Systems A/S, Oslo, Norway
   Chris Armstrong, Brookhaven National Lab (OS/2)
   William Bader, Moravian College
   Fuat Baran, CUCCA
   Stan Barber, Rice U
   Jim Barbour, U of Colorado
   Donn Baumgartner, Dell
   Nelson Beebe, U of Utah
   Karl Berry, UMB
   Dean W Bettinger, SUNY
   Gary Bilkus
   Marc Boucher, U of Montreal
   Charles Brooks, EDN
   Bob Brown
   Mike Brown, Purdue U
   Jack Bryans, California State U at Long Beach
   Mark Buda, DEC (VAX/VMS)
   Bjorn Carlsson, Stockholm University Computer Centre QZ, Sweden
   Bill Catchings, formerly of CUCCA
   Bob Cattani, Columbia U CS Dept
   Davide Cervone, Rochester University
   Seth Chaiklin, Denmark
   John Chandler, Harvard U / Smithsonian Astronomical Observatory
   John L Chmielewski, AT&T, Lisle, IL
   Howard Chu, U of Michigan
   Bill Coalson, McDonnell Douglas
   Bertie Coopersmith, London, UK
   Chet Creider, University of Western Ontario, Canada
   Alan Crosswell, CUCCA
   Jeff Damens, formerly of CUCCA
   Mark Davies, Bath U, UK
   S. Dezawa, Fujifilm, Japan
   Joe R. Doupnik, Utah State U
   Frank Dreano (Honeywell)
   John Dunlap, University of Washington
   David Dyck, John Fluke Mfg Co.
   Bernie Eiben, DEC
   Kristoffer Eriksson, Peridot Konsult AB, Oerebro, Sweden
   John R. Evans, IRS, Kansas City
   Glenn Everhart, RCA Labs
   Herm Fischer, Encino, CA (extensive contributions to version 4.0)
   Carl Fongheiser, CWRU
   Marcello Frutig, Catholic University, Sao Paulo, Brazil (X.25 support)
   Hirofumi Fujii, Japan Nat'l Lab for High Energy Physics, Tokyo (Kanji)
   Chuck Fuller, PSC
   Andy Fyfe, Caltech
   Christine M. Gianone, CUCCA
   John Gilmore, UC Berkeley
   German Goldszmidt, IBM
   Alistair Gorman, New Zealand
   Chris Green, Essex U, UK
   Alan Grieg, Dundee Tech, Scotland, UK
   Yekta Gursel, MIT
   Jim Guyton, Rand Corp
   Michael Haertel
   Marion Hakanson
   John Hamilston, Iowa State U
   Simon Hania, Netherlands
   Stan Hanks, Rice U.
   Ken Harrenstein, SRI
   James Harvey, Indiana/Purdue U (VMS)
   Rob Healey
   Chuck Hedrick, Rutgers U
   Ron Heiby, Technical Systems Division, Motorola Computer Group
   Steve Hemminger, Tektronix
   Christian Hemsing, RWTH Aachen, Germany (OS-9)
   Andrew Herbert, Monash Univ, Australia
   Mike Hickey, ITI
   R E Hill
   Bill Homer, Cray Research
   Randy Huntziger, National Library of Medicine
   Larry Jacobs, Transarc
   Steve Jenkins, Lancaster University, UK
   Mark B Johnson, Apple Computer
   Eric F Jones, AT&T
   Luke Jones, AT&T
   Peter Jones, U of Quebec Montreal
   Phil Julian, SAS Institute
   Mic Kaczmarczik, U of Texas at Austin
   Sergey Kartashoff, Inst. of Precise Mechanics & Computer Equipment, Moscow
   Howie Kaye, CUCCA
   Rob Kedoin, Linotype Co, Hauppauge, NY (OS/2)
   Mark Kennedy, IBM
   Terry Kennedy, St Peter's College, Jersey City, NJ (VAX/VMS, 2.11 BSD)
   Douglas Kingston, morgan.com
   Tom Kloos, Sequent Computer Systems
   Jim Knutson, U of Texas at Austin
   David Kricker, Encore Computer
   Thomas Krueger, UWM
   Bo Kullmar, Central Bank of Sweden, Kista
   John Kunze, UC Berkeley
   Bob Larson, USC (OS-9)
   Bert Laverman, Groningen U, Netherlands
   Steve Layton
   David Lawyer, UC Irvine
   S.O. Lidie, Lehigh U
   Tor Lillqvist, Helsinki University, Finland
   Dean Long
   Kevin Lowey, U of Saskatchewan (OS/2)
   Andy Lowry, Columbia University
   David MacKenzie, Environmental Defense Fund, University of Maryland
   John Mackin, University of Sidney, Australia
   Martin Maclaren, Bath U, UK
   Chris Maio, Columbia U CS Dept
   Fulvio Marino, Olivetti, Ivrea, Italy
   Peter Mauzey, AT&T
   Tye McQueen, Utah State U
   Ted Medin
   Hellmuth Michaelis
   Leslie Mikesell, American Farm Bureau
   Martin Minow, DEC (VAX/VMS)
   Pawan Mistra, Bellcore
   Ken Mizialko, IBM, Manassas, VA
   Ray Moody, Purdue U
   Bruce J Moore, Allen-Bradley Co, Highland Heights, OH (Atari ST)
   Steve Morley, Convex
   Peter Mossel, Columbia University
   Tony Movshon, NYU
   Lou Muccioli, Swanson Analysis Systems
   Dan Murphy
   Gary Mussar
   John Nall, FSU
   Jack Nelson, University of Pittsburgh
   Jim Noble, Planning Research Corporation (Macintosh)
   Ian O'Brien, Bath U, UK
   John Owens
   Andre Pirard, University of Liege, Belgium
   Paul Placeway, Ohio State U (Macintosh & more)
   Piet W. Plomp, ICCE, Groningen University, Netherlands
   Ken Poulton, HP Labs
   Manfred Prange, Oakland U
   Frank Prindle, NADC
   Tony Querubin, U of Hawaii
   Anton Rang
   Scott Ribe
   Alan Robiette, Oxford University, UK
   Michel Robitaille, U of Montreal (Mac)
   Kai Uwe Rommel, Technische Universitat Munchen (OS/2)
   Larry Rosenman (Amiga)
   Jay Rouman, U of Michigan
   Jack Rouse, SAS Institute (Data General and/or Apollo)
   Stew Rubenstein, Harvard U (VAX/VMS)
   Bill Schilit, Columbia University
   Eric Schnoebelen, Convex
   Benn Schreiber, DEC
   Dan Schullman, DEC (modems, DIAL command, etc)
   John Schultz, 3M
   Steven Schultz, Contel (PDP-11)
   APPP Scorer, Leeds Polytechnic, UK
   Gordon Scott, Micro Focus, Newbury UK
   Gisbert W. Selke, WIdO, Bonn, Germany
   David Sizeland, U of London Medical School
   Fridrik Skulason, Iceland
   Dave Slate
   Bradley Smith, UCLA
   Richard S Smith, Cal State
   Ryan Stanisfer, UNT
   Bertil Stenstroem, Stockholm University Computer Centre (QZ), Sweden
   Peter Svanberg, Royal Techn. HS, Sweden
   Andy Tanenbaum, Vrije U, Amsterdam, Netherlands
   Markku Toijala, Helsinki U of Technology
   Rick Troxel, NIH
   Warren Tucker, Tridom Corp, Mountain Park, GA
   Dave Tweten, AMES-NAS
   G Uddeborg, Sweden
   Walter Underwood, Ford Aerospace
   Pieter Van Der Linden, Centre Mondial, Paris
   Ge van Geldorp, Netherlands
   Fred van Kempen, MINIX User Group, Voorhout, Netherlands
   Wayne Van Pelt, GE/CRD
   Mark Vasoll, Oklahoma State U (V7 UNIX)
   Konstantin Vinogradov, ICSTI, Moscow
   Paul Vixie, DEC
   Dimitri Vulis, CUNY
   Roger Wallace, Raytheon
   Stephen Walton, Calif State U, Northridge (Amiga)
   Jamie Watson, Adasoft, Switzerland (RS/6000)
   Rick Watson, U of Texas (Macintosh)
   Robert Weiner
   Lauren Weinstein
   Joachim Wiesel, U of Karlsruhe, Germany
   Michael Williams, UCLA
   Nate Williams, U of Montana
   David Wilson
   Patrick Wolfe, Kuck & Associates, Inc.
   Gregg Wonderly, Oklahoma State U (V7 UNIX)
   Farrell Woods, Concurrent (formerly Masscomp)
   Dave Woolley, CAP Communication Systems, London
   Jack Woolley, SCT Corp
   Frank Wortner
   Ken Yap, U of Rochester
   John Zeeff, Ann Arbor, MI

1.2. Introduction

C-Kermit is a communication software program written in C that provides a full
implementation of the Kermit file transfer protocol, plus terminal connection,
modem dialing, file management, and a powerful script programming language.  An
important goal of C-Kermit is transportability to different computers and
operating systems.  To date, C-Kermit (one release or another) has been adapted
to UNIX (most versions), VAX/VMS, Data General AOS/VS, IBM OS/2, the Apple
Macintosh, the Commodore Amiga, the Atari ST, Apollo Aegis, OS-9, NCR 9800/VE,
and others.

C-Kermit offers you several methods of interaction.  On UNIX, VAX/VMS, and most
other systems, you have access to Kermit's interactive command parser, and you
can also invoke Kermit with command line options.  On workstations like the
Macintosh, there is a mouse-and-window interface with pull-down menus, radio
buttons, and so forth.  In some cases, you have both.

Interactive operation gives you full access to all of C-Kermit's features.
Command-line invocation gives you access to a small but useful subset.
Command-line operation is described in Section 1.15.

The main part of document concentrates on the general features of C-Kermit.
Sections specific to certain systems -- UNIX, VAX/VMS, OS/2, the Amiga, OS-9 --
appear at the end.  Material about some of the implementations remains to be
added.  Macintosh Kermit will be documented in a separate publication.

PLEASE NOTE: This manual describes a full-featured version of C-Kermit.
However, some computers do not have address spaces (or C compilers, or linkers)
capable of supporting all Kermit's features, so some features might be missing
from your version.  See the file ckuins.doc for details.

1.3. Kermit Software for Other Computers

Kermit software is available from Columbia University for almost every known
computer and operating system, written in a wide variety languages.  For a
catalog of Kermit software and ordering information, write to:

  Kermit Distribution
  Columbia University Center for Computing Activities
  612 West 115th Street
  New York, NY  10025
  USA

or call:

  (USA) [phone]

MS-DOS Kermit for the IBM PC, PS/2, and compatibles is also available in
bookstores, computer stores, and from the publisher:

  Christine M. Gianone, Using MS-DOS Kermit, Second Edition, Digital Press,
  Bedford, MA, 1991, 345 pages.  Packaged with MS-DOS Kermit for the IBM PC,
  PS/2, and compatibles on a 5.25-inch diskette.

      Order Number: EY-H893E-DP
      Digital Press ISBN: 1-55558-082-3
      Prentice Hall ISBN: 0-13-952276-X

      Internation Edition Order Number: EY-H893E-DI
      International Prentice Hall ISBN: 0-13-953043-6

  US single-copy price: $34.95; quantity discounts available.  Available in
  computer bookstores or directly from Digital Press.  In the USA, call Digital
  Press toll-free 1-800-344-4825 to order; major credit cards accepted.
  Overseas, order through your bookstore or your local Digital Equipment
  Corporation branch.

A German-language edition is also available:

  Christine M. Gianone, MS-DOS Kermit, Das universelle Kommunikationsprogramm,
  Verlag Heinz Heise, Hannover, Germany (1991), 414 pages.  Translated by
  Gisbert W. Selke.  Packaged with version 3.11 of MS-DOS Kermit for the IBM
  PC, PS/2, and compatibles on a 5.25-inch diskette, including German language
  help files.  ISBN 3-88229-006-4

1.4. Interactive Operation

C-Kermit's interactive command prompt is "C-Kermit>".  In response to this
prompt, you can type any valid interactive C-Kermit command.  C-Kermit executes
the command and then prompts you for another command.  The process continues
until you instruct the program to terminate.

Commands begin with a keyword, normally an English verb, such as "send".  You
may omit trailing characters from any keyword, as long as you specify
sufficient characters to distinguish it from any other keyword valid in that
field.  Certain commonly-used keywords (such as "send", "receive", "connect")
also have special non-unique abbreviations ("s" for "send", "r" for "receive",
"c" for "connect").

Command keywords can be entered in either upper or lower case, or any
combination.  This manual shows command keywords in uppercase for clarity.

Certain characters have special functions while you are typing interactive
commands:

    ?   Question mark, typed at any point in a command, will produce a message
        explaining what is possible or expected at that point.  Depending on
        the context, the message may be a brief phrase, a menu of keywords, or
        a list of files.  Use "?" liberally to feel your way through Kermit's
        commands.

    ESC (The Escape or Altmode key) -- Request completion of the current
        keyword or filename, or insertion of a default value.  The result will
        be a beep if the requested operation fails.

    TAB (The horizontal Tab key) -- Same as ESC.

    DEL (The Delete or Rubout key) -- Delete the previous character from the
        command.  You may also use BS (Backspace, Control-H) for this function.

    ^W  (Control-W) -- Erase the rightmost word from the command line.

    ^U  (Control-U) -- Erase the entire command.

    ^R  (Control-R) -- Redisplay the current command.

    ^C  (Control-C) -- Interrupt a command.

    SP  (Space) -- Delimits fields (keywords, filenames, numbers) within a
        command.

    CR  (Carriage Return) -- Enters the command for execution.  LF (Linefeed)
        or FF (formfeed) may also be used for this purpose.

    \   (Backslash) -- Enter any of the above characters into the command
        literally.  To enter a backslash, type two backslashes in a row (\\).
        A backslash at the end of a command line causes the next line to be
        treated as a continuation line; this is useful for readability in
        command files.  Backslash is also used to introduce special characters,
        variable names, and functions.  These are explained in Section 1.12.

    ^Z  (Control-Z) -- On systems (like Berkeley UNIX, Ultrix) with job
        control, Control-Z is supposed to suspend Kermit, i.e. put it into the
        background in such a way that it can be brought back into the
        foreground (e.g. with an 'fg' shell command) with all its settings
        intact.

You may type the editing characters (DEL, ^W, etc) repeatedly, to delete all
the way back to the prompt.  No action will be performed until the command is
entered by typing carriage return, linefeed, or formfeed.  If you make any
mistakes, you will receive an informative error message and a new prompt --
make liberal use of `?' and ESC to feel your way through the commands.  One
important command is "help" -- you should use it the first time you run
C-Kermit.

Comments may be entered as entire commands, or may appear at the end of any
command.  Comments are introduced by semicolon (;) or pound sign (#).

Interactive C-Kermit accepts commands from files as well as from the keyboard.
When you start C-Kermit, the program looks for a special file, the Kermit
Initialization File in your home or current directory (first it looks in the
home directory, then in the current one) and executes any commands it finds
there.  These commands must be in interactive format, not command-line format.
The name of the initialization file is .kermrc in UNIX and OS-9, and
CKERMIT.INI in most other operating systems.

Here is a brief list of C-Kermit interactive commands:

              ;  Introduce a full-line or trailing comment (also #).
              !  Execute a system command or enter system command interpreter.
              @  Same as !.
            ASK  Prompt the user, store user's reply in a variable.
           ASKQ  Like ASK, but, but doesn't echo (useful for passwords).
         ASSIGN  Assign an evaluated string to a variable or macro.
            BUG  Instructions for reporting bugs.
            BYE  Terminate and log out a remote Kermit server.
             CD  Change Working Directory (also, CWD).
          CLEAR  Clear communication device input buffer.
          CLOSE  Close a log or other local file.
        COMMENT  Introduce a full-line comment.
        CONNECT  Establish a terminal connection to a remote computer.
        DECLARE  Declare an array.
      DECREMENT  Subtract one (or other number) from a variable.
         DEFINE  Define a variable or macro.
         DELETE  Delete a file or files.
           DIAL  Dial a telephone number.
      DIRECTORY  Display a directory listing.
        DISABLE  Disallow access to selected features during server operation.
             DO  Execute a macro.
           ECHO  Display text on the screen.
           ELSE  ELSE-part of an IF command.
         ENABLE  Allow access to selected features during server operation.
            END  A command file or macro.
           EXIT  Exit from the program, closing all open files and devices.
         FINISH  Instruct a remote Kermit server to exit, but not log out.
            FOR  Execute commands repeatedly in a counted loop.
            GET  Get files from a remote Kermit server.
           GOTO  Go to a labeled command in a command file or macro.
         HANGUP  Hang up the phone or network connection.
           HELP  Display a help message for a given command.
             IF  Conditionally execute the following command.
      INCREMENT  Add one (or other number) to a variable.
          INPUT  Match characters from another computer against a given text.
            LOG  Open a log file -- debugging, packet, session, transaction.
           MAIL  Send a file as electronic mail to a specified address.
          MSEND  Multiple SEND -- send a list of files.
           OPEN  Open a local file for reading or writing.
         OUTPUT  Send text to another computer.
            PAD  (X.25 version only) Give X.25 PAD commands.
          PAUSE  Do nothing for a given number of seconds.
          PRINT  Print a local file on a local printer.
           PUSH  Invoke host system interactive command interpreter.
            PWD  Display current working device/directory.
           QUIT  Same as EXIT.
           READ  Read a line from a local file.
        RECEIVE  Passively wait for files to arrive.
         REDIAL  Redial the most recently dialed phone number.
        REINPUT  Reexamine text previously received from another computer.
         REMOTE  Issue file management commands to a remote Kermit server.
         RENAME  Change the name of a file.
         RETURN  Return from a user-defined function.
            RUN  Run a program or system command.
         SCRIPT  Execute a UUCP-style login script.
           SEND  Send files.
         SERVER  Begin server operation.
            SET  Set various parameters.
           SHOW  Display values of SET parameters.
          SPACE  Display current disk space usage.
     STATISTICS  Display statistics about most recent transaction.
           STOP  Stop executing macro or command file and return to the prompt.
        SUSPEND  Put the Kermit program in the backgound.
           TAKE  Execute commands from a file.
         TELNET  Start a TCP/IP TELNET session.
       TRANLATE  Translate a file's character set.
       TRANSMIT  Upload a file with no error checking.
           TYPE  Display a file on the screen.
        VERSION  Display the program version number on the screen.
           WAIT  Wait for the specified modem signals.
          WHILE  Execute commands repeatedly while a condition is true.
          WRITE  Write text to a local file.
            XIF  Extended IF command.

On most computers, C-Kermit can be started simply by typing the word "kermit"
(followed by carriage return).  If no command-line "action options" are
included, Kermit will automatically enter interactive prompting mode.  Let's
begin by looking at a few of C-Kermit's basic interactive commands.  Most
important of all when you are just beginning are the commands to exit from the
program and to get help about it.


The EXIT and QUIT Commands

Syntax: EXIT [ number ] Syntax: QUIT [ number ]

These two commands are identical.  Both of them do the following:

   - Hangs up the modem, if the communications line supports data terminal
     ready.
   - Relinquish access to any communication line assigned via SET LINE, or
     any network connection obtained via SET HOST.
   - Relinquish any uucp and multiuser locks on the communications line
     (UNIX only).
   - Close all open logs or other files.
   - Attempt to insure that your terminal is returned to normal.

After exit from C-Kermit, your default directory will be the same as when you
started the program.  The EXIT command is issued implicitly whenever C-Kermit
halts normally, e.g. after a command line invocation, or after certain kinds of
interruptions.

C-Kermit returns an exit status of zero, except when an error is encountered,
where the exit status is set to a nonzero number, depending on the operating
system.  In UNIX, the exit status is the sum of 1 (if any SEND commands
failed), 2 (if any RECEIVE or GET commands failed), and 4 (if any REMOTE
commands failed).  If you give a number after the EXIT or QUIT command, that
number is returned instead.


The HELP Command

Syntax: HELP [ { command, { SET, REMOTE } parameter } ]

Brief help messages or menus are always available at interactive command level
by typing a question mark at any point.  A slightly more verbose form of help
is available through the HELP command.  The HELP command with no arguments
prints a brief summary of how to enter commands and how to get further help.
HELP may be followed by one of the top-level C-Kermit command keywords, such as
SEND, to request information about a command.  Commands such as SET and REMOTE
have a further level of help.  Thus you may type HELP, HELP SET, or HELP SET
PARITY; each will provide a successively more detailed level of help.


The TAKE Command

Syntax: TAKE fn1

The TAKE command instructs C-Kermit to execute commands from the named file.
The file may contain any interactive C-Kermit commands, including TAKE; command
files may be nested to any reasonable depth, but it may not contain text to be
sent to a remote system during the CONNECT command; Use scripts for that (see
sections 1.13 and 1.14).

Echoing of commands from TAKE files and handling of errors during TAKE file
execution are controlled by the SET TAKE command.

Comments may be included in take-command files.  Whole-line comments may begin
with the word COMMENT.  Both trailing and whole-line comments can be introduced
using semicolon or pound sign, for example:

    COMMENT - Commands to dial out out using a Hayes modem...
    set modem hayes        ; Specify the kind of modem
    set line /dev/ttyh8    ; Select a terminal device
    set speed 19200        ; Set the speed
    dial 7654321           ; Dial the number

TAKE-command files are in exactly the same syntax as interactive commands.  If
you want to include special characters like question mark or backslash that you
would have to quote with backslash when typing interactive commands, you must
quote these characters the same way in command files.  Long lines may be
continued by ending them with a single backslash or a dash:

    set\
    modem\
    hayes
    set-
    line /dev-
    /ttyh8

Continued lines cannot have trailing comments.  If you put a trailing comment
after the dash, then Kermit will not treat the line as continued.  If you put a
dash at the end of a trailing comment, then Kermit will treat the next line as
a continuation of the comment.

An implicit TAKE command is executed upon your C-Kermit initialization file
(.kermrc in UNIX, CKERMIT.INI elsewhere) when C-Kermit starts up, upon either
interactive or command-line invocation.  The initialization file may contain
SET or other commands you want to be in effect at all times.  For instance, you
might want override the default action when incoming files have the same names
as existing files -- in that case, put a command like:

    set file collision overwrite

Under UNIX, you may also use the shell's redirection mechanism to cause
C-Kermit to execute commands from a file:

    kermit < cmdfile

or you can even pipe commands in from another process:

    command | kermit


1.5. Establishing the Connection

In order to talk about a connection between two computers, we a way to
distinguish between them.  The local computer is the one that you are using
most directly -- a PC or workstation on your desk, or a timesharing computer
that you are using from a terminal.  Kermit lets you make a connection from the
local computer to a remote computer, for example by dialing it up with a modem.
The Kermit program on your local computer is said to be in "local mode" and the
Kermit program on the remote computer is in "remote mode".

C-Kermit can be used in either remote or local mode.  If you are using C-Kermit
in remote mode, you can skip ahead to Section 1.6, File Transfer.

If you are using C-Kermit in local mode, you must have one of three kinds of
connections to the remote computer:

   1. A hardwired asynchronous serial connection, either directly to the
      other computer, or through some kind of terminal server or switching
      device.

   2. A dialup connection, which you establish by dialing with a modem.

   3. A network connection.

To prepare C-Kermit for these connections, several preliminary steps are
necessary using the SET command, which is described in Section 1.11, below:

   1. Direct connection: SET LINE device-name, SET SPEED bits-per-second.

   2. Dialup connection, which you establish by dialing with a modem: SET
      MODEM modem-type, SET LINE device-name, SET SPEED bits-per-second,
      DIAL phone-number.

   3. Network connection: SET HOST network-host-name.  If your version of
      C-Kermit supports more than one type of network, give the
      appropriate SET NETWORK command before the SET HOST command (the
      default network type is TCP/IP).  (Also see the TELNET command,
      described below.)

In addition, you must establish whatever other communication related settings
are appropriate for the connection, including PARITY, DUPLEX, FLOW, and
HANDSHAKE.  Having done all this, you can use the CONNECT command to begin a
terminal session with the remote computer, and once connected, you can initiate
file transfers.


The SET LINE Command

Syntax: SET LINE [ device ]

Close any previously open network, terminal, or modem connection.  If a device
name is given, try to open the device for communication.  If no device name is
given, revert to the default mode of communication (normally remote mode).


The SET HOST Command

Syntax: SET HOST [ host [ service ] ]

Close any previously open network, terminal, or modem connection.  If the
current network type (see SET NETWORK) is TCP/IP, the host field can be
specified as an IP host name or a numeric IP host address, followed optionally
by a TCP service name or port number (the default service is TELNET, TCP port
number 23).  If the network type is X.25, the host field is an X.121 address,
and there is no service field.  If no host name is given, revert to the default
mode of communication (normally remote mode).


The CONNECT Command

The CONNECT command (C is a special abbreviation for CONNECT) links your
terminal to another computer as if it were a local terminal to that computer,
through the device specified in the most recent SET LINE or SET HOST command,
or through the default device if your system is a PC or workstation.  All
characters you type at your keyboard are sent out the communication line (and
if you have SET DUPLEX HALF, also displayed on your screen), and all characters
arriving at the communication port are displayed on the screen.  Current
settings of speed, parity, duplex, and flow-control are honored, and the data
connection is 7 bits wide unless you have given the command SET TERMINAL
BYTESIZE 8.  If you have issued a LOG SESSION command, everything you see on
your screen will also be recorded to your session log.  This provides a way to
"capture" files from remote systems that don't have Kermit programs available.

To get back to your own system, you must type the "escape character", which is
Control-Backslash (^\) unless you have changed it with the SET ESCAPE command,
followed by a single-character command, such as C for "close connection".
Single-character commands may be entered in upper or lower case.  They include:

  C     Return to C-Kermit.  If you gave an interactive CONNECT command, return
        to the C-Kermit prompt.  If you gave a -c or -n option on the command
        line, close the connection and return to the system prompt.
  B     Send a BREAK signal (about 0.275 sec).
  L     Send a Long BREAK signal (about 1.5 sec).
  0     (zero) send a null.
  S     Give a status report about the connection.
  H     Hangup the phone.
  !     Escape to the system command processor "under" Kermit.  Exit or logout
        to return to your CONNECT session.
  Z     Suspend Kermit (UNIX only).
  \nnn  A character in backslash-code form.
  ^\    Send Control-Backslash itself (whatever you have defined the escape
        character to be, typed twice in a row sends one copy of it).

Uppercase and control equivalents for (most of) these letters are also
accepted.  A space typed after the escape character is ignored.  Any other
character will produce a beep.

The connect command simply displays incoming characters on the screen.  It is
assumed any screen control sequences sent by the host will be handled by the
firmware or emulation software in your terminal or PC(Several C-Kermit
implementations include terminal emulators, notably Macintosh and OS/2).

It is sometimes useful to see exactly what characters the host is transmitting,
rather than having your terminal or emulator interpret them for you.  If you
give the command SET DEBUG SESSION, then during CONNECT, C-Kermit will display
control characters using "uparrow" notation, for example ^A for Control-A, ^B
for Control-B, etc, ^[ for ESC.  8-bit characters are preceded by a tilde (~)
character.


The DIAL and REDIAL Commands

Syntax: DIAL telephone-number
Syntax: REDIAL

The DIAL command controls dialout modems; you should have already issued a SET
MODEM command to identify the type of modem to be used for dialing, and then
SET LINE and SET SPEED commands to identify the terminal device to which the
modem is connected, plus any desired SET CARRIER and SET DIAL commands to
modify the behavior of the DIAL command itself.

In the DIAL command, you supply the phone number and the Kermit program feeds
it to the modem in the appropriate format and then interprets dialer return
codes and modem signals to inform you whether the call was completed.  These
actions are based upon built-in knowledge of the control sequences and
responses of each make and model of modem that C-Kermit knows about.

The telephone-number may contain imbedded modem-dialer commands appropriate to
the selected modem type, such as comma for Hayes pause, or `&' for Ventel
dialtone-wait and `%' for Ventel pause (consult your modem manual for details).

The REDIAL command is exactly like the DIAL command, except it uses the phone
number you specified in your most recent DIAL command.

At the time of this writing, support is included for the following modems:

   - AT&T 7300 Internal Modem
   - AT&T 2212C, 2224B, 2224CEO, and 2296A switched network modems in AT&T
     mode
   - AT&T Digital Terminal Data Module (DTDM)
   - Cermetek Info-Mate 212A
   - Concord Condor CDS 220
   - Courier HST
   - DEC DF03-AC
   - DEC DF100 Series
   - DEC DF200 Series
   - General DataComm 212A/ED
   - Hayes Smartmodem and compatibles
   - IBM/Siemens/Rolm 9751 CBX DCM
   - Microcom AX-9624
   - Penril
   - Racal Vadic
   - Telebit Trailblazer, T1000, T1600, T2500
   - US Robotics 212A
   - Ventel

Support for new modems is added to the program from time to time; you can check
the current list by typing SET MODEM ?.

There are also two "generic" modem types -- DIRECT (i.e. no modem at all, so
that no attempt is made to deal with modem signals), and UNKNOWN (which tells
C-Kermit to attempt to honor modem signals, but leaves the dialing mechanism
unspecified).  NONE is a synonym for DIRECT.

The device used for dialing out is the one selected in the most recent SET LINE
command (or on a workstation, the default line if no SET LINE command was
given).  On UNIX systems, the DIAL command attempts to lock the terminal
device's path and to establish a call on an exclusive basis.  If it is desired
to dial a call and then return to the shell (such as to do Kermit activities
depending on standard in/out redirection), it is necessary to place the dialed
call under one device name (say, "/dev/cua0") and then escape to the shell
within Kermit on a linked device which is separate from the dialed line (say,
"/dev/cul0").  This is the same technique used by uucp (to allow locks to be
placed separately for dialing and conversing).

Because modem dialers have strict requirements to override the carrier-detect
signal most UNIX implementations expect, the sequence for dialing is more rigid
than most other C-Kermit procedures.  Example:

    kermit
    C-Kermit>set modem hayes      ; SET MODEM first!
    C-Kermit>set carrier auto     ; Then SET CARRIER if necessary,
    C-Kermit>set line /dev/acu2   ; Then SET LINE,
    C-Kermit>set speed 2400       ; Then SET SPEED,
    C-Kermit>set dial display on  ; Then SET DIAL if necessary,
    C-Kermit>dial 9,5551212       ; and finally, DIAL.
    Connected!                    ; If DIAL completes OK,
    C-Kermit>connect              ; you can CONNECT.
    logon, do things
    ^\c
    C-Kermit> ...
    C-Kermit>quit                 ; Disconnect & unlock the line.

In general, C-Kermit requires that the modem provide the "carrier detect" (CD)
signal when a call is in progress, and remove that signal when the call
completes or the line drops.  If a modem switch setting is available to force
CD, it should normally not be in that setting.  C-Kermit also requires (on most
systems) that the modem track the computer's "data terminal ready" (DTR)
signal.  If a switch setting is available to simulate DTR asserted within the
modem, then it should normally not be in that setting.  Otherwise the modem
will be unable to hang up at the end of a call or when interrupts are received
by Kermit.

If you want to interrupt a DIAL command in progress (for instance, because you
just realize that you gave it the wrong number), type a Control-C get back to
command level.  If you are a UNIX user and your "interrupt character" is
defined as something besides Ctrl-C, use that instead.

PROBLEMS: The DIAL command hangs up the phone (see HANGUP) prior to dialing.
Because of the problems described for HANGUP, certain UNIX configurations are
unable to use DIAL when it does this.  To work around this problem, give the
command SET DIAL HANGUP OFF before giving the DIAL command.  If DIAL still
doesn't work right, start over again but this time give the command SET CARRIER
OFF prior to SET LINE.

See the command summary for a description of SET DIAL options.  You can use SET
DIAL to modify the modem initialization string, the timeout period for call
completion, and so on.

Hayes and Hayes-compatible, as well as Telebit, modem dialing is supported for
both word and digit result codes, and C-Kermit will also attempt to adjust its
communication speed in case these modems complete a call at a lower speed than
it was placed at (if you have a speed-matching modem, you can defeat this
action by giving the command SET DIAL SPEED-MATCHING ON before dialing).


The HANGUP Command

The HANGUP command attempts to hang up the modem on a local-mode dialout
connection established by SET LINE, or to hang up the network connection
established by SET HOST, in order to break the connection.  On terminal
devices, Kermit accomplishes the hangup by momentarily turning off the Data
Terminal Ready (DTR) RS-232 signal.

The means used to drop DTR and bring it back up again are highly dependent on
the computer, the version of UNIX, the communication device, the device driver,
the modem being used, and even the cable that connects the modem to the
communication device.  Therefore you might find that this command fails to
operate as it should.

If the HANGUP command fails to hang up a phone connection, then maybe your
modem is configured to ignore DTR.  You should make sure your modem is
configured to pay attention to the computer's DTR signal.  Another possibility
is that your cable is giving the modem a constant DTR signal, looped back from
its own DSR signal; in that case, replace your cable with a regular
straight-through modem cable.

If the HANGUP command does indeed hang up the phone connection, but then you
can't communicate with the modem any more to establish a new connection, your
version of UNIX may have dropped the DTR signal without bringing it back up
again properly.  To work around this problem, give the SET LINE command (with
no device name) to close the current device, and then another SET LINE command
specifying the original device to open it again.


The TELNET Command

Syntax: TELNET [ host [ service ] ]

The TELNET command can be used in C-Kermit implementations that support TCP/IP
networking.  TELNET is simply a shorthand for SET HOST followed by CONNECT.  If
you give an IP host name (or number), Kermit closes any currently open
connection and begins a new one to the given host.  If the TCP/IP connection is
made successfully, Kermit puts itself into CONNECT mode for terminal emulation.
If you give a TELNET command without a hostname, the currently active TCP/IP
session (if any) is resumed; if there is no current session, you'll get an
error message.  The service can be a TCP port number or service name; the
default is 23, the TELNET port.


1.6. File Transfer

Kermit programs can transfer files correctly and completely, using the Kermit
file transfer protocol.  A Kermit program must be running on both computers.
Here is the normal procedure:

   1. Run Kermit on your local computer.

   2. Make the appropriate communication settings (such as modem type,
      line, speed, parity, etc).

   3. Establish a connection to the remote computer (DIAL if necessary).

   4. CONNECT to the remote computer.

   5. Log in to the remote computer if necessary.

   6. Start Kermit on the remote computer and tell it to send (or receive)
      a file (or files).

   7. "Escape back" to the local computer.

   8. Tell the local computer to receive (or send) a file (or files).

When transferring files, C-Kermit converts between upper and lower case
filenames and between LF and CRLF line terminators automatically, unless told
to do otherwise.  When binary files must be transferred, the program should be
instructed not to perform LF/CRLF conversion (-i on the command line or SET
FILE TYPE BINARY interactively; see below).

If C-Kermit is in local mode, the screen is continously updated to show the
progress of the file transer.  A dot is printed for every four data packets,
other packets are shown by type:

    I Exchange Parameter Information
    R Receive Initiation
    S Send Initiatiation
    A Attribute Packet
    F File Header
    G Generic Server Command
    C Remote Host Command
    N Negative Acknowledgement (NAK)
    E Fatal Error
    T Indicates a timeout occurred
    Q Indicates a damaged, undesired, or illegal packet was received
    % Indicates a packet was retransmitted

You may type the following interruption commands during file transfer:

    F Interrupt the current File, and go on to the next (if any).
    X Interrupt the entire Batch of files, terminate the operation.
    R Resend the current packet.
    E Error: terminate the current operation immediately and return to prompt.
    A Display a status report for the current operation.

EMERGENCY EXIT:  When running C-Kermit in remote mode, if you have started a
protocol operation (sending or receiving a file, server command wait, etc), you
can type two Control-C's directly to the UNIX Kermit program ("connect" first
if necessary):

    Control-C Control-C

This will cause the program to display,

    ^C^C...

and return you to the C-Kermit prompt.

Before initiating a file transfer, you should be sure that all communication
and protocol-related settings are correct.  Version 5A of Kermit attempts to
make things easier for you in this area in several ways, for example by
recognizing file attributes (text or binary, character set, etc) from the other
Kermit if it sends them.  If your parity is set to NONE, C-Kermit automatically
recognizes parity bits on received packets, and adjusts its parity accordingly.
But it's better to set these C-Kermit parameters directly yourself to avoid any
confusion that might result from these automatic adjustments.


The SEND Command

Syntax:  SEND fn [ rfn1 ]

Send the file or files denoted by fn to the other Kermit, which should be
running as a server, or which should be given the RECEIVE command.  The SEND
command may be abbreviated to S, even though S is not a unique abbreviation for
a top-level C-Kermit command.  Each file is sent under its own name (as
described above, or as specified by the 'set file names' command).  If the
second form of the SEND command is used, i.e. with fn1 denoting a single file,
rfn1 may be specified as a name to send it under.  For example:

    send sows.ear silk.purse

sends the file sows.ear but tells the other Kermit that its name is silk.purse.


The MSEND Command

Syntax:  MSEND fn [ fn [ fn [ ... ] ] ]

The MSEND command also sends one or more files, but unlike the SEND command, it
allows you to give a list of files to send, and it does not allow you to
specify an alternate name.  The MSEND file specifications are separated by
spaces.

Both the SEND and MSEND commands allow you to use wildcard (meta) characters to
specify groups of files.  Exactly which wildcard characters are available
depend on the host operating system and other factors.  In VAX/VMS, they are
`*' and `%'.  In UNIX they are `~', `*', and `?'.  If `?'  is to be included,
it must be prefixed by `\' to override its normal function of providing help.
The `*' character matches any string, and `?' (UNIX) or `%' (VMS) matches any
single character.

When fn contains `*' or `?' characters, there is a limit to the number of files
that can be matched, which varies from system to system.  If you get the
message "Too many files match" then you'll have to make a more judicious
selection.  For example, if fn was of the form:

    usr/longname/anotherlongname/*

then C-Kermit's string space will fill up rapidly -- try using CD to change
your directory to the path in question and reissuing the command.

Wildcards do not descend through a directory tree.  Only files in the current
or specified directory are sent.

In UNIX versions of C-Kermit only, `~' is treated as a meta character if it is
the first character in the file specification. If it is followed immediately by
a slash, a space, or end of line, then your login directory name is
substituted.  If it is followed immediately by a username, then that user's
login directory name is substituted.  (In VAX/VMS, you can use logical names in
the file specification for the same purpose.)

Wildcard Notation for UNIX

Normally, C-Kermit expands wildcard characters itself by searching through the
disk and matching names against the pattern you specify.  But Kermit's
pattern-matching abilities are limited to the metacharacters listed above.
UNIX shells like csh and ksh, on the other hand, offer notations for file
groups, like `[bcdfhjlns]og' or `*.{txt,doc}' that Kermit cannot handle on its
own.  Kermit lets you get at these capabilities with the command:

SET WILDCARD-EXPANSION { KERMIT, SHELL }

The default is KERMIT, meaning Kermit itself expands wildcards in SEND and
MSEND, as well as what it receives while in server mode from GET commands.  The
SHELL option means Kermit calls upon the user's preferred shell (via the SHELL
environment variable, or failing that, the user's login shell via getpwuid) to
expand them.

Advantages of the SHELL method include more flexibility in file selection,
consistency with the user's shell, and ability to handle a larger number of
files.  But there are drawbacks.  It's noticably slower.  Characters in
filenames that are special to the shell (like |, &, `, etc) must be quoted with
\ (this is not necessary when Kermit expands).  And the same Kermit command
(SEND, MSEND, or GET sent to a server) may behave differently depending on what
your login shell is.  For example, "{aaa,bbb}" is expanded by the csh, but
taken literally by sh and ksh; "[a-z]" is expanded by csh and ksh, but taken
literally by sh.

The expansion is done by passing "echo " concatenated with your filespec to the
shell.  This assumes that echo is a built-in shell command, or if it's not,
then the echo program is in the user's path (risky).  "echo" is used rather
than "ls -d" because ls says "xxx not found" if xxx does not exist
(unfortunately, the csh version of "echo" says "echo: no match" if you give it
a string containing metacharacters and no files match, wherease sh and ksh
simply echo the string back at you).  It doesn't matter much, because C-Kermit
checks each word that is returned for its existence as a file (but of course,
you could have a file called "echo:", "no", or "match"...).  And then what
happens if your have a file called "-n"?  ("echo -n" is a command.  Refer to a
file called "-n" in the current directory as "./-n").

Text vs Binary Files

When C-Kermit sends each file, it also sends certain information about the file
in an "attribute packet", provided the other Kermit agrees to accept attribute
packets.  This information includes the size, type (text or binary, determined
from the "-i" command-line option or the "set file type" command), creation
date, and a code to let the other Kermit know that the file is being sent from
a UNIX system.  The other Kermit may accept or refuse the file based upon these
attributes, for example, if it doesn't have enough disk space to store a file
of the specified size.

The file type attribute allows C-Kermit, when sending a file, to tell the
receiving whether it should be in text or binary mode.  Therefore, if the
receiving Kermit has this feature, it is not necessay to give it a SET FILE
TYPE command to "match modes" with C-Kermit.

Note -- C-Kermit sends only from the current or specified directory.  It does
not traverse directory trees.  If the source directory contains subdirectories,
they will be skipped.  By the same token, C-Kermit does not create directories
when receiving files.  If you have a need to do this, you can pipe tar through
C-Kermit, as shown in the example in section 1.15, or under AT&T System III/V
UNIX you can use cpio, or BACKUP under VAX/VMS, etc.

Another Note -- The SEND command skips over "invisible" files that match the
file specification; UNIX systems usually treat files whose names start with a
dot (like .login, .cshrc, and .kermrc) as invisible.  If you want to send
these, include the dot in your filespec, as in:

    send .*


The RECEIVE Command

Syntax:  RECEIVE [fn1]

Passively wait for files to arrive from the other Kermit, which must be given
the SEND command -- the RECEIVE command does not work in conjunction with a
server (use GET for that).  If fn1 is specified, store the first incoming file
under that name.  The RECEIVE command may be abbreviated to R.

Incoming file data is normally decoded and stored according to whether C-Kermit
is in text or binary mode.  But if the other Kermit sends the file-type
attribute, this will override C-Kermit's file-type setting on a per-file basis.
Therefore, it is possible for another Kermit program to send C-Kermit a mixture
of text and binary files, so long as the type of each file is indicated in the
Attribute packet.  For text files, C-Kermit will perform character-set
translation if a known transfer character set is indicated in the Attribute
packet (see section on International Characters).

C-Kermit also attempts to store the incoming file with the creation date that
is specified in the Attribute packet.  C-Kermit does not attempt to verify disk
space against the announced size of the incoming file.

You can control C-Kermit's use of these attributes using the SET ATTRIBUTE
command.


The STATISTICS Command

The STATISTICS command displays information about the most recent Kermit file
transfer or other protocol transaction, including file and communication line
input and output, timing and efficiency, as well as what encoding options were
in effect (such as 8th-bit prefixing, repeat-count compression, packet lengths,
window size).


Non-Protocol Data Transfers

It is also possible to transfer files with other computers that do not have a
Kermit program available.  To send a file to such a computer, use the TRANSMIT
command:

Syntax: TRANSMIT fn1

This command sends the named file without error checking, obeying current
settings for file type (text or binary), parity, and duplex.

In text mode, send the file a line at a time, with character translations done
according to the current file and transfer character sets, using the SET
TRANSMIT PROMPT character (linefeed, \10, by default) as a line turnaround
character.  That is, send a line from the file, wait until the prompt character
comes in response, then send the next line, and so on.  If zero (0) is
specified for the prompt character, then send the whole file without waiting
for any response or echo from the host.  Don't try this unless you know that
the host can successfully process long continuous bursts of input characters.
Each line is terminated by a carriage return, just as you would type it at a
terminal.  Linefeeds are stripped unless you have given the command SET
TRANSMIT LINEFEED ON.  The computer to which you are transmitting the file
should be prepared to receive it, for instance into a text editor.

In binary mode, send all the characters of the file with no modification and no
line turnaround handshake (the TRANSMIT PROMPT setting is ignored).  Use binary
mode only if you know that the computer or device to which you are transmitting
the file can receive arbitrary patterns of characters at full speed.

If you want to transmit 8-bit data over a 7-bit connection (i.e. PARITY is not
NONE), you can use SET TRANSMIT LOCKING-SHIFT ON to have Kermit send SO/SI
shifts around your 8-bit characters.  The TRANSMIT command can be interrupted
by typing Ctrl-C.  Also see SET TRANSMIT.

The opposite of TRANSMIT is LOG SESSION, which lets you capture files or screen
data from remote computers during CONNECT, also without error checking.

XMIT may be used as a synonym for TRANSMIT in the TRANSMIT, SET TRANSMIT, and
SHOW TRANSMIT commands.


1.7. Being and Using a Kermit Server

The SERVER command places C-Kermit in "server mode" on the currently selected
communication device or network connection.  All further commands must arrive
as valid Kermit packets from the Kermit on the other end of the line.  If you
are running C-Kermit on the remote computer, then you should escape back to
your local computer after you give C-Kermit the SERVER command, and then issue
all further commands to the C-Kermit server from your local Kermit's command
prompt.  It is also possible to work the other way: your local computer is the
Kermit server and the remote computer issues the commands -- this can only work
if the remote Kermit is driven by a TAKE command file (which should end with
the command FINISH).

The C-Kermit server can respond to the following commands from the client:

  Client Command         Server Response
    GET                    Sends files
    SEND                   Receives files
    MAIL                   Sends incoming files as e-mail to specified address
    BYE                    Attempts to log itself out
    FINISH                 Exits to level from which it was invoked
    REMOTE CD              Changes working directory (also, remote cd)
    REMOTE DIRECTORY       Sends directory listing
    REMOTE DELETE          Removes files
    REMOTE HELP            Lists these capabilities
    REMOTE HOST            Executes a UNIX shell command
    REMOTE KERMIT          Sends a Kermit command to a Kermit server
    REMOTE LOGIN           Login to a Kermit server that requires this
    REMOTE LOGOUT          Logout from a Kermit server
    REMOTE PRINT           Receives a file and prints it
    REMOTE SET             Changes its settings
    REMOTE SPACE           Reports about its disk usage
    REMOTE TYPE            Sends files to your screen
    REMOTE WHO             Shows who's logged in

If the Kermit server is directed at an external line (i.e. it is in "local
mode") then the console may be used for other work if you SET FILE DISPLAY OFF
and run it in the background; normally the program expects the console to be
used to observe file transfers and enter status queries or to interrupt
commands.  The way to get C-Kermit into background operation from interactive
command level varies from system to system (e.g. on Berkeley UNIX you would
halt the program with ^Z and then use the C-Shell 'bg' command to continue it
in the background).  The more common method is to invoke the program with the
desired command line arguments, including "-q", and with a terminating "&".

The C-Kermit server will accept a list of files in GET commands sent by the
client, similar to the list you can give to the MSEND command, e.g.:

    MS-Kermit>get ~joe/new.txt /etc/termcap ../*.c

The file specifications are separated by spaces.  If you need to include a
space in a filename, quote it with a backslash, for example:

    MS-Kermit>get node"user\ passwd"::dev:[dir]name.ext

If you need to include a backslash, use two of them.

When the UNIX Kermit server is given a REMOTE HOST command, it executes it
using the shell invoked upon login, e.g. the Bourne shell, the Korn Shell, or
the Berkeley C-Shell (or whatever the user has set her SHELL environment
variable to be).

The server can issue periodic NAK packets.  You can control the rate at which
this happens via SET SERVER TIMEOUT.  Specifiying a value of zero instructs
C-Kermit not to do this at all.  A nonzero value, n, makes a NAK appear every n
seconds during server command wait.  This is useful if the client Kermit is not
capable of timeouts, and a packet that it sends to the server is lost.  The
default server timeout is zero.

SECURITY.  Before putting C-Kermit into server mode, you can give it commands
to restrict the types of access it allows to clients.  The command is DISABLE.
You can turn these accesses back on using the ENABLE command.  Here are the
items that can be controlled in this way, with the effect of DISABLE noted.
CAUTION: If you leave HOST enabled, the client can get around some of these
restrictions with REMOTE HOST commands.

BYE             Ignore BYE commands from the client, stay in server mode.
CD              Don't let the client change directories, or send files to, or
                get files from, or delete or type files in, any but the current
                directory, nor inquire about space in any but the current
                directory.
DELETE          Don't let the client delete any files.
DIRECTORY       Don't let the client request a directory listing.
FINISH          Ignore FINISH commands from the client, stay in server mode.
GET             Don't let the client GET files.
HOST            Ignore REMOTE HOST commands from the client.
SEND            Don't accept files that the client tries to send.
SET             Refuse REMOTE SET commands from the client.
SPACE           Refuse REMOTE SPACE commands from the client.
TYPE            Refuse REMOTE TYPE commands from the client.
WHO             Refuse REMOTE WHO commands from the client.
ALL             All of the above.


Using a Kermit Server

C-Kermit may itself request services from a remote Kermit server.  To send a
file to a Kermit server, use the SEND command, just as you would to send a file
to a Kermit program that has been given the RECEIVE command.  But you cannot
use the RECEIVE command to get a file from a Kermit server, because the RECEIVE
command just waits passively for a file to arrive, but the server has not been
told which file to send.  For this, you need the GET command:

Syntax:  GET rfn

        or: GET
                rfn
                fn1

The GET command requests a remote Kermit server to send the named file or
files, it must be used in place of RECEIVE.  Since a remote file specification
(or list) might contain spaces, which normally delimit fields of a C-Kermit
command, an alternate form of the command is provided to allow the inbound file
to be given a new name: type GET alone on a line, and you will be prompted
separately for the remote and local file specifications, for example:

    C-Kermit>get
     Remote file specification: profile exec
     Local name to store it under: profile.exec

If a `?' is to be included in the remote file specification, you must prefix it
with `\' to suppress its normal function of providing help.

If you have started a multiline GET command, you may escape from its lower-
level prompts by typing a carriage return in response to the prompt, e.g.

    C-Kermit>get
     Remote file specification: foo
     Local name to store it under: (Type a carriage return here)
    (cancelled)
    C-Kermit>

After the GET command has been entered, the file transfer proceeds exactly as
if you had given a SEND command to the other Kermit and a RECEIVE command to
this one.

In addition to SEND and GET, the following commands may also be sent from
C-Kermit to a Kermit server.  If the server does not support a command that you
send to it, it will respond with a message like "Unknown server command" or
"Unimplemented REMOTE command".

    REMOTE CD [directory]
        Request the server to change its default directory (and/or device) to
        the one you specify.  If none is specified, the server is requested to
        return to its primary default directory (normally the login directory).


    REMOTE DELETE rfn
        The server is requested to delete the specified file or files.


    REMOTE DIRECTORY [rfn]
        The server is requested to send a directory listing of the specifed
        files.  If no files are specified, then the server should send a
        listing of all the files in the current directory.


    REMOTE HELP
        The server is requested to send to your screen a list of the commands
        that you may issue to it from your local Kermit.


    REMOTE HOST command
        The server is requested to ask its host operating system to execute the
        given command.


    REMOTE KERMIT command
        The remote server is requested to execute the given command, which is
        in its own (Kermit program) syntax.


    REMOTE LOGIN userid password [account]
        If a remote Kermit server has been set up to require to provide a user
        ID and password before you can gain access to it, use this command to
        send it the user ID and password.


    REMOTE LOGOUT
        Remove your access from a remote Kermit server that you have REMOTE
        LOGIN'ed to.


    REMOTE PRINT file [options]
        The file is sent to the server, which is requested via Attribute packet
        to print it on its printer using the specified print options.


    REMOTE SET parameter value
        The server is requested to set the given parameter to the specified
        value.  Use question mark to find out what parameters and values are
        available.  The meanings of these parameters and values are explained
        in the section on the SET command, below.  Perhaps the most useful one
        is REMOTE SET FILE TYPE { TEXT, BINARY }.


    REMOTE SPACE [dir]
        The server is requested to report on available disk space in the
        specified device and/or directory, or in the current area if none
        specified.


    REMOTE TYPE [rfn]
        The server is requested to send the specified file for display on your
        screen.


    REMOTE WHO [user]
        The server is requested to send a list of the users who are logged in
        on its computer.  If a username is given, information about that user
        is requested.


    BYE and FINISH:
        When connected to a remote Kermit server, these commands cause the
        remote server to terminate; FINISH returns it to Kermit or system
        command level (depending on the implementation or how the program was
        invoked); BYE also requests it to log itself out.


1.8. International Character Sets

Text files may be written in languages other than English, and in most cases
that means that they contain non-ASCII characters such as accented letters,
special punctuation marks, etc.  Many different character sets have been
devised to represent different languages.  These character sets are sometimes
specific to a particular computer manufacturer, and sometimes they conform to
one standard or another.  The Kermit file transfer protocol permits Kermit
programs to exchange files written in different character sets by translating
between each computer's local file character set and a standard set that is
used "on the wire".  Here are the relevant commands:

    SET FILE TYPE TEXT
        Character set translation is not done at all unless the file type is
        text.


    SET TRANSFER CHARACTER-SET name
        Tell C-Kermit which character set is to be used on the wire, i.e.
        within the Kermit packets.  The choices are TRANSPARENT (no
        translation, this is the default), ASCII (translate to/from US ASCII),
        LATIN1 (ISO 8859-1 Latin Alphabet 1), CYRILLIC-ISO (ISO 8859-5
        Latin/Cyrillic Alphabet), and JAPANESE-EUC.  Synonym: SET XFER
        CHARACTER-SET.


    SET FILE CHARACTER-SET name
        Tell C-Kermit which character set is used in the local file, ASCII, or
        any of a dozen or so 7-bit national replacement character sets (NRCs)
        such as ITALIAN, NORWEGIAN, etc, or an 8-bit character set like LATIN1,
        DEC-Multinational, DG-International, NEXT (for NeXT workstations),
        CP437 or CP850 (for IBM or Xenix systems), APPLE (for A/UX on the
        Macintosh); CP866, KOI8-CYRILLIC, CYRILLIC-ISO, and SHORT-KOI for
        Cyrillic; and JAPANESE-EUC, DEC-KANJI, SHIFT-JIS, and JIS7 for Japanese
        Kanji.


    SET LANGUAGE name
        Enable certain language-specific translations, especially for DUTCH,
        ICELANDIC, GERMAN, RUSSIAN, and the Scandinavian languages.  In
        particular, SET LANGUAGE RUSSIAN makes Kermit treat ASCII as if it were
        SHORT-KOI when it is a FILE or TRANSFER character set, and the
        corresponding TRANSFER or FILE character set is an 8-bit Cyrillic set.


    TRANSLATE file1 cs1 cs2 [ file2 ]
        Translate the local file file1 from the character set cs1 into the
        character set cs2.  Both character sets may be selected from C-Kermit's
        repertoire of file character sets.  The result is stored in file2 or
        (if file2 is not specified), displayed on the screen.  If LANGUAGE is
        set to RUSSIAN, ISO Latin-Cyrillic is used as the intermediate standard
        character set during translation, otherwise ISO Latin Alphabet 1 is
        used.  Does not yet work for Kanji.

The SET commands are described in more detail later.

When sending a file, C-Kermit translates the file from the specified file
character set into the specified transfer character set, and an identifier for
the selected transfer character set is included in the file attribute packet,
if use of attribute packets has been negotiated and a SET ATTR [CHARACTER-SET]
OFF command has not been given.

When receiving, C-Kermit translates from the specified transfer character set
to the specified file character set or, if a transfer character set is
identified in the incoming attribute packet it is used instead.  If the file
character set is ASCII and special characters are being received, then they are
translated by stripping diacritical marks and aiming for the closest possible
1-to-1 translation on a per-character basis.  But if a SET LANGUAGE command has
been given, special translations can be done.  For example if LANGUAGE has been
set to GERMAN and the local file character set is ASCII, and a file arrives
with a transfer character set of LATIN1, then C-Kermit will translate German
umlaut-vowels into the corresponding vowels followed by the letter e, and
German double-s into two s's.  Similar translations take effect for other
languages.

If unwanted effects appear because of Kermit's translation, you can disable
this feature with SET ATTRIBUTE CHARACTER-SET OFF.

When transferring text that contains long runs of 8-bit data over a 7-bit
communication channel, efficiency can be improved with the following command:

    SET TRANSFER LOCKING-SHIFT { OFF, ON, FORCED }
        Specifies whether locking shifts should be used by Kermit when encoding
        and decoding packets.  A locking shift is a special character, Ctrl-N
        (Shift-Out, SO), that means that all the following characters, up to
        the next Ctrl-O (Shift-In, SI), are to have their 8th bits set to 1
        upon receipt.  For long runs of 8-bit characters, this is more
        efficient than Kermit's regular "single shift" method of prefixing each
        8-bit character by an &-sign.  Synonym: SET XFER LOCKING-SHIFT.  The
        options are:

        ON  This is the default setting.  If PARITY is not NONE, try to
            negotiate the use of locking shift protocol with the other Kermit,
            and use it if the other Kermit agrees.  If PARITY is NONE, locking
            shifts won't be used.


        OFF Don't use locking shifts.


        FORCED
            Use locking shifts, regardless of the parity setting and
            negotiations.  Automatically disables the use of 8th-bit prefixing
            (single shifts).  For the file sender, this command lets data be
            sent to the receiver with embedded SO and SI characters, which can
            be processed properly by many terminals, printers, and other
            devices.  For the file receiver, this command forces the treatment
            of SO and SI characters in the data as shift commands.

Locking shifts are most effective for text written in non-Roman alphabets and
encoded in standard 8-bit character sets like ISO Latin/Cyrillic, ISO
Latin/Arabic, ISO Latin/Hebrew, ISO Latin/Greek, or Japanese EUC.
Locking-shift status is displayed by the SHOW and STATISTICS commands.


1.9. Logging Things

Kermit's actions during terminal connection and file transfer can be logged in
several ways, using the LOG command:

Syntax: LOG {DEBUGGING, PACKETS, SESSION, TRANSACTIONS} [ fn1 [
 { APPEND, NEW }=NEW ] ]

C-Kermit's progress may be logged in various ways.  The LOG command opens a
log, the CLOSE command closes it.  In addition, all open logs are closed by the
EXIT and QUIT commands.  A name may be specified for a log file; if the name is
omitted, the file is created with a default name as shown below.  If the
keyword APPEND is included at the end of the command, then if the specified
file exists, it is appended to rather than written over; if it does not exist,
a new file is created.

LOG DEBUGGING
    This produces a voluminous log of the internal workings of C-Kermit, of use
    to Kermit developers or maintainers in tracking down suspected bugs in the
    C-Kermit program.  Use of this feature slows down the Kermit protocol and
    fills up your disk.  Default name: debug.log.


LOG PACKETS
    This produces a record of all the packets that go in and out of the
    communication port.  This log is of use to Kermit maintainers who are
    tracking down protocol problems in either C-Kermit or any Kermit that
    C-Kermit is connected to.  Default name:  packet.log.


LOG SESSION
    This log will contain a copy of everything you see on your screen during
    the CONNECT command, except for local messages or interaction with local
    escape commands.  Default name:  session.log.


LOG TRANSACTIONS
    The transaction log is a record of all the files that were sent or received
    while transaction logging was in effect.  It includes time stamps and
    statistics, filename transformations, and records of any errors that may
    have occurred.  The transaction log allows you to have long unattended file
    transfer sessions without fear of missing some vital screen message.
    Default name:  transact.log.

The CLOSE command closes the named log, e.g. CLOSE DEBUG, CLOSE SESSION.

Note:  Debug and Transaction logs are a compile-time option; C-Kermit may be
compiled without these logs, in which case it will run faster, it will take up
less space on the disk, but the commands relating to them will not be present.


1.10. Local File Management

C-Kermit allows the following local file management functions from its
interactive command level:

CD [directory-name]
    Changes Kermit's working device and/or directory to the one given, or to
    the user's default directory and/or device if the name is omitted.  This
    command affects only the Kermit process and any processes it may
    subsequently create.  You may use CWD and SET DEFAULT as synonyms for CD.

DELETE fn
    Deletes (removes, erases) file fn, which may be the name of a single file
    or a wildcard specification containing * and/or ?  characters.  You may use
    RM as a synonym for DELETE.

DIRECTORY [fn]
    Displays a listing of the files whose names match fn, which may be the name
    of a single file or a wildcard specification containing * and/or ?
    characters.  If no fn is given, C-Kermit lists all files in the current
    device and/or directory.  The format of and information provided in the
    listing depends on the operating system.  You may use LS as a synonym for
    DIRECTORY.

PWD (Print Working Directory) Display the current working (default) file device
    and/or directory.  You may use SHOW DEFAULT as a synonym for PWD.

PRINT fn1 [ options ]
    Print the local file fn1 on a local printer.  Options can be included after
    the filename, for example, to select a particular printer.  The options are
    in the format of the local system's printing command.

RENAME fn1 fn2
    Changes the name of file fn1 to fn2.  You may use MV as a synonym for
    RENAME.

SPACE
    Displays information about disk space and/or quota in the current directory
    and device.

TYPE fn
    Display the named file on the screen.  May be interrupted with Ctrl-C, and
    on most systems the display can be stopped and resumed with Ctrl-S and
    Ctrl-Q, respectively.  You may use CAT as a synonym for TYPE.

{ @, !, RUN, PUSH }
    The command is executed by your computer's operating system command
    interpreter (UNIX shell, VMS DCL, etc).  If no command is specified, then
    an interactive session is started; exiting from this session, e.g. by
    typing Control-D or 'exit' to a UNIX shell, or LOGOUT to VMS DCL, will
    return you to C-Kermit command level.  Use the `!' command to provide file
    management or other functions not explicitly provided by C-Kermit commands.
    !, @, RUN, and PUSH are all synonyms for the same command.


1.11. The SET and SHOW Commands

Since Kermit is designed to allow diverse computers to communicate, it is often
necessary to issue special instructions to allow Kermit to adapt to
peculiarities of the other computer or the communication path.  These
instructions are accomplished by the SET command.  The following parameters may
be SET:

     ATTRIBUTES  Turn Attribute packet processing on or off.
     BACKGROUND  Force foreground or background mode.
    BLOCK-CHECK  Level of packet error detection.
        BUFFERS  Send and receive packet buffer sizes.
        CARRIER  Treatment of carrier on terminal connections.
           CASE  Controls treatment of alphabetic case.
        COMMAND  Character set size for commands.
          COUNT  For counted loops.
          DEBUG  Log or display debugging information.
        DEFAULT  Default directory.
          DELAY  How long to wait before sending first packet.
           DIAL  Parameters for DIAL command.
         DUPLEX  Specify which side echoes during CONNECT.
         ESCAPE  Prefix for "escape commands" during CONNECT.
           FILE  Set various file parameters.
   FLOW-CONTROL  Communication line full-duplex flow control.
      HANDSHAKE  Communication line half-duplex turnaround character.
           HOST  Specify network host name.
     INCOMPLETE  Disposition for incompletely received files.
          INPUT  Control behavior of INPUT command.
       LANGUAGE  Enable language-specific character-set translations.
           LINE  Communication line device name.
          MACRO  Control aspects of macro execution.
   MODEM-DIALER  Type of modem-dialer on communication line.
            PAD  (X.25 systems only) X.3 PAD parameters.
         PARITY  Communication line character parity.
         PROMPT  The C-Kermit program's interactive command prompt.
        RECEIVE  Parameters for inbound packets.
          RETRY  Packet retransmission limit.
         SCRIPT  Parameters for the SCRIPT command.
           SEND  Parameters for outbound packets.
         SERVER  Parameters for server operation.
    SESSION-LOG  (UNIX only) Session log file type, text or binary.
          SPEED  Communication line speed.
        SUSPEND  Enable/Disable SUSPEND.
           TAKE  Control aspects of TAKE file execution.
       TERMINAL  Terminal parameters.
       TRANSFER  File transfer parameters.
       TRANSMIT  Control aspects of TRANSMIT command execution.
        UNKNOWN  Specify handling of unknown character sets.
         WINDOW  File transfer packet window size.
       WILDCARD  (UNIX only) Kermit vs shell wildcard expansion.
           X.25  (X.25 systems only) X.25 call parameters

The SHOW command may be used to display current settings.  Here is a summary of
settings available in C-Kermit, listed alphabetically.

SET ATTRIBUTES
    Tells C-Kermit whether to exchange file attribute (A) packets, or whether
    to include specified attributes within the A packets it sends, or whether
    to pay attention to specific attributes in A packets it receives.  When the
    use of A packets has been negotiated, C-Kermit enables and uses the ones
    listed below.  When sending files, C-Kermit responds to an Attribute
    refusal from the other computer by not sending the specified file.  For
    example, if C-Kermit announces in the A packet that the file is 100K long,
    the other Kermit could refuse the file because of insufficient disk space,
    and then C-Kermit would not send it.

    SET ATTRIBUTE CHARACTER-SET { ON, OFF }
        Turn the character-set attribute ON or OFF.  If ON, C-Kermit includes a
        code for the transfer character set in the A packet when sending a
        file, and when receiving a file, C-Kermit will translate from the
        character set (if any) specified in the incoming A packet into the
        current file character set (see SET FILE), if the transfer character
        set is known to C-Kermit (see SET UNKNOWN).


    SET ATTRIBUTE DATE { ON, OFF }
        If ON, C-Kermit includes the file's creation date in the A packet when
        sending a file, and stores incoming files with the creation dates (if
        any) given in the incoming A packets.  Beware: on some computers,
        incremental backups might skip over files with creation dates older
        than the most recent backup.


    SET ATTRIBUTE DISPOSITION { ON, OFF }
        The MAIL and REMOTE PRINT commands work by setting "dispositions" of
        Mail and Print in the A packet when sending a file.  SET ATTR DISP OFF
        will cause C-Kermit to ignore this and store such files on disk rather
        than mailing or printing them.


    SET ATTRIBUTE LENGTH { ON, OFF }
        When sending files, C-Kermit puts their length in the A packet, so the
        receiving system has an opportunity to check and/or allocate disk space
        in advance, and to refuse the file if there is not enough disk space.
        If you believe that files are being unjustly refused on the basis of
        length, you can SET ATTR LENGTH OFF.  When receiving files, C-Kermit
        presently ignores the length announced in the A packet.


    SET ATTRIBUTE OS-SPECIFIC { ON, OFF }
        Certain versions of Kermit convey operating-system specific file
        information in the A packet, which is primarily useful when
        transferring files between like systems, such as VMS to VMS.  If you
        find this feature is interfering with successful file transfer, SET
        ATTR OS OFF.


    SET ATTRIBUTE SYSTEM-ID { ON, OFF }
        The A packet also includes a code identifying the file's operating
        system of origin, so that the receiver of the file can decide whether
        to pay attention to the OS-SPECIFIC attribute.  Use SET ATTR SYS OFF to
        disable this feature.


    SET ATTRIBUTES ALL { ON, OFF }
        You can turn all the above off using SET ATTR ALL OFF, and back on
        using SET ATTR ALL ON.


    SET ATTRIBUTES { ON, OFF }
        This command turns the attribute mechanism itself on or off, without
        disturbing the settings of the individual attributes.  It is on by
        default.



SET BACKGROUND { OFF, ON }
    Use SET BACKGROUND off to make your prompts and messages appear in case
    they have disappeared because Kermit thinks it is running in the background
    (for example, if you are running it through an output filter, as in "kermit
    | vt100").  You can accomplish the same effect using the -z option on the
    command line.


SET BLOCK-CHECK {1, 2, 3}
    Determines the level of per-packet error detection.  "1" is a single-
    character 6-bit checksum, folded to include the values of all bits from
    each character.  "2" is a 2-character, 12-bit checksum.  "3" is a
    3-character, 16-bit cyclic redundancy check (CRC).  The higher the block
    check, the better the error detection and correction and the higher the
    resulting overhead.  Type 1 is most commonly used; it is supported by all
    Kermit implementations, and it has proven adequate in most circumstances.
    Types 2 or 3 should be used when transferring 8-bit data or when using long
    packets.


SET BUFFERS n1 n2
    Allows you to change the total buffer space used for sending packets (n1)
    and receiving packets (n2), if Kermit has been configured to allow dynamic
    buffer allocation.  The bigger you make them, the longer your packets can
    be, and the more window slots you can use.  To see the default values for
    your version of Kermit, type SHOW PROTOCOL.


SET CARRIER {AUTO, ON [n], OFF}
    Specifies C-Kermit's treatment of the Carrier (CD, DCD, or RLSD) RS-232
    signal on terminal device connections obtained via SET LINE:

    SET CARRIER ON
        Means to require carrier at all times; SET LINE will not return until
        carrier appears (handy for setting Kermit up to wait for a call to come
        in), and a fatal error will occur if carrier disappears during CONNECT
        or file transfer.  A nice side effect is that when you log out from the
        remote computer, you will be put back at C-Kermit prompt level
        automatically if the remote system drops carrier properly.  If you want
        to set a time limit on how long SET LINE will wait for carrier, you can
        include an optional number after SET CARRIER ON to specify the number
        of seconds to wait before timing out and returning to the prompt, for
        example SET CARRIER ON 30.


    SET CARRIER OFF means to ignore carrier at all times.  Useful for direct,
        nonmodem connections, or misbehaving modem connections.  Should only be
        used when necessary, because it takes away the ability of Kermit to
        automatically detect a broken phone connection.


    SET CARRIER AUTO means to require carrier during CONNECT but not at other
        times.  AUTO is the default.  SET CARRIER ON does not affect the DIAL
        command.



SET CASE { ON, OFF }
    Tells C-Kermit whether to pay attention to or ignore alphabetic case in
    string matching operations, including INPUT and IF.  Default is OFF, i.e.
    ignore case.


SET COMMAND BYTESIZE { 7, 8 }
    Normally, C-Kermit's command processor strips off the 8th bit of any
    character you type, in case your data connection to C-Kermit has parity.
    If there is no parity and you want to use an 8-bit international character
    set in your commands (for example, in the ECHO command, or in filenames),
    use SET COMMAND BYTESIZE 8.  The command also applies to the connection
    between your terminal (if any) and C-Kermit during terminal emulation
    (CONNECT), as opposed to the connection between C-Kermit and the remote
    host (see SET TERMINAL BYTESIZE).


SET COUNT n
    For use with counted loops.  See the section on script language
    programming.


SET DEFAULT directory
    Change default directory.  Equivalent to CD.


SET DIAL DISPLAY { ON, OFF }
    Show dialing activity on screen.


SET DIAL HANGUP { ON, OFF }
    Normally, the DIAL command will attempt to hang up the phone before dialing
    a new call.  This is done by momentarily dropping the Data Terminal Ready
    (DTR) signal on the currently selected terminal device.  Unfortunately, the
    method for doing this is ill-defined in some versions of UNIX, and in some
    cases DTR goes down and stays down, which can prevent all further
    communication between the computer and the modem.  If you find that the
    DIAL command does not work for you at all, try giving the command SET DIAL
    HANGUP OFF before giving the DIAL command.  This will prevent DIAL from
    hanging up the phone before dialing the new call.


SET DIAL INIT-STRING string
    Replace Kermit's built-in initialization string with string, which may
    contain backslash codes to represent control characters.


SET DIAL MNP-ENABLE { ON, OFF }
    Enable or disable MNP protocol negotiations by the modem.  Normally off.
    This command presently applies only to Telebit modems.


SET DIAL KERMIT-SPOOF { OFF, ON }
    Enable modem's "Kermit spoof" if it has one.


SET DIAL SPEED-MATCHING { OFF, ON }
    Tells whether the modem's interface speed is locked.  Default is OFF,
    meaning the modem changes its interface speed to match the connection
    speed, for example if you place a call at 2400 bps and it is answered at
    1200 bps.  Use ON if your modem is configured to do speed matching.


SET DIAL TIMEOUT number
    Seconds to wait for a response from the modem when dialing before giving up
    and declaring that the call could not be completed.  If you don't give this
    command, Kermit calculates its own dial timeout based on the modem type,
    length of the phone number, and transmission speed.  If that interval isn't
    long enough, use this command to specify a longer one.


SET DEBUG { ON, OFF, SESSION }
    SET DEBUG ON is equivalent to LOG DEBUG.  SET DEBUG SESSION means to
    display incoming control and 8-bit characters on the screen using special
    notation (see CONNECT).  SET DEBUG OFF turns off all debugging.


SET DELAY n
    How many seconds to wait before sending the first packet after a SEND
    command.  Used in remote mode to give you time to escape back to your local
    Kermit and issue a RECEIVE command before the first Kermit packet appears.
    Normally 5 seconds.


SET DUPLEX {FULL, HALF}
    For use during CONNECT.  Specifies which side is doing the echoing; FULL
    means the other side, HALF means C-Kermit must echo your keystrokes itself.
    Normally FULL.  Use half when communicating with IBM mainframes over
    linemode connections, and on similar half-duplex or local-echo connections.
    Synonym: SET LOCAL-ECHO {OFF, ON}.


SET ESCAPE-CHARACTER cc
    For use during CONNECT to get C-Kermit's attention.  The escape character
    acts as a prefix to an escape command, for instance to close the connection
    and return to C-Kermit or UNIX command level.  The normal escape character
    is Control-Backslash (ASCII 28).  See CONNECT.


SET FILE parameter value
    Establish file-related parameters:

    SET FILE BYTESIZE { 7, 8 }
        Normally 8.  If 7, strip the 8th bit from file data during file
        transfer.


    SET FILE CHARACTER-SET name
        tells the encoding of the local file, ASCII by default.  The names
        DUTCH, GERMAN, FRENCH, etc, refer to 7-bit ASCII-based national
        replacement character (NRC) sets.  CP866, CYRILLIC-ISO, and
        KOI8-CYRILLIC refer to sets used in the Soviet Union and other
        countries that use the Cyrillic alphabet.  Latin-1 is the 8-bit ISO
        8859 Latin Alphabet 1.  JAPANESE-EUC, DEC-KANJI, JIS7, and SHIFT-JIS
        are Japanese Kanji sets.  Type SET FILE CHAR ? for a complete list.
        When receiving files, C-Kermit translates from the transfer character
        set specified in the most recent SET TRANSFER CHARACTER-SET command or
        else the one announced in the Attribute packet (if any) into the file
        character set.  When sending files, C-Kermit translates from the
        current file character set into the current transfer character set.


    SET FILE COLLISION action
        Tells what to do when a file arrives that has the same name as an
        existing file.  The actions are:

        BACKUP
            (default) Rename the old file to a new, unique name and store the
            incoming file under the name it arrived with.  The "new unique"
            name is simply a new generation on VAX/VMS.  In UNIX, a "generation
            number" appended to the filename, separated by a tilde, as in
            oofa.txt.~8~[The new name for the arriving file is of the form
            foo.~n~, where foo is the name they share and n is a "generation
            number"; if foo exists, then the new file will be called foo.~1~.
            If foo and foo.~1~ exist, the new file will be foo.~2~, and so on.
            If the new name would be longer than the maximum length for a
            filename, then characters are deleted from the end first, for
            instance, thelongestname on a system with a limit of 14 characters
            would become thelonges.~1~.]

                WARNING: UNIX C-Kermit presently offers no method of
                automatically limiting the number of versions of a file
                that can be created, so if too many of them pile up, you'll
                have to delete the ones you don't need by hand.  Or,
                because the version number syntax is compatible with GNU
                EMACS backup files, you can use EMACS to do this for you.

            In OS/2, Kermit constructs names of the form FZZn.BAR, where
            FZZ.BAR is the name they share and n is a "generation number"; if
            FZZ.BAR exists, then the new file will be called FZZ00001.BAR.  If
            FZZ.BAR and FZZ00001.BAR exist, the new file will be FZZ00002.BAR,
            and so on.  If the common name were more than 6 characters long (eg
            GOODDATA.DAT), then the new name for the arriving file would be
            GOODD001.DAT and so on.


        OVERWRITE
            Overwrite (replace) the existing file.  The existing file is gone,
            destroyed.  Even if the file transfer fails or the incoming file is
            refused.  Use with caution.


        APPEND
            Append the incoming file to the end of the existing file.  This
            option is useful for adding information to a log file, but it
            should be used with caution to avoid, for example, joining two
            files of different types (like text and binary).


        DISCARD
            Refuse and/or discard the incoming file.  This option is handy for
            resuming multi-file transmissions that were broken.  Only those
            files that were not successfully transferred before will be
            accepted.


        RENAME
            Give the incoming file a unique name, like the BACKUP option,
            except that the incoming file gets the new name, rather than the
            existing file.


        UPDATE
            Accept the incoming file only if it is newer than the existing
            file.  This feature depends on the creation date field in the
            attribute packet.



    SET FILE DISPLAY { ON, OFF }
        Normally ON; when in local mode, display progress of file transfers on
        the screen (stdout), and watch the keyboard for interruptions.  If OFF
        (-q on command line) none of this is done, and the file transfer may
        proceed in the background oblivious to any other work concurrently done
        at the keyboard.


    SET FILE NAMES {CONVERTED, LITERAL}
        Normally CONVERTED, which means that outbound filenames have device,
        directory, and/or path specifications stripped, lowercase letters
        raised to upper, tildes and extra periods changed to X's, and an X
        inserted in front of any name that starts with period.  In VMS, the
        generation number is also stripped.  For UNIX only, incoming filenames
        have uppercase letters lowered.  LITERAL means that none of these
        conversions are done; therefore, any directory path appearing in a
        received file specification must exist and be write-accessible.  When
        literal naming is being used, the sender should not use path names in
        the file specification unless the same path exists on the target system
        and is writable.


    SET FILE RECORD-LENGTH n
        Tells the record length for fixed-format files, or the maximum record
        length for variable-format files, on systems like VAX/VMS where
        record-length is a meaningful concept.


    SET FILE TYPE {BINARY, TEXT}
        The file type is normally text, which means that conversion is done
        between the local computer's record format and Kermit's standard
        transfer format, for example between UNIX newline characters and
        Kermit's carriage-return/linefeed sequences.  BINARY means to transmit
        file contents without conversion.  Binary (`-i' in command line
        notation) is necessary for binary files, and desirable in all file
        transfers between like systems to cut down on overhead.


    For VAX/VMS, these are the file type options:


    SET FILE TYPE TEXT
        Regular Text mode.  Applies to incoming files only.  When SENDing
        files, C-Kermit determines their type automatically.


    SET FILE TYPE BINARY [ { FIXED, UNDEFINED } ]
        Applies to incoming files only.  Binary mode: incoming files are stored
        with no translation or conversion.  The default record format is FIXED,
        but you can specify UNDEFINED too.


    SET FILE TYPE IMAGE
        This one applies to both incoming and outbound files.  For incoming
        files, it's just like BINARY FIXED.  For outbound files, it means just
        send the blocks of the file as they are stored on the disk, and ignore
        the file's RMS attributes.  SET FILE TYPE BLOCK is a synonym (for
        compatibility with Kermit-32).


    SET FILE WARNING { ON, OFF }
        SET FILE WARNING is an old command, somewhat misnamed.  SET FILE
        COLLISION (above) should be used instead.  SET FILE WARNING ON is
        equivalent to SET FILE COLLISION RENAME and SET FILE WARNING OFF is
        equivalent to SET FILE COLLISION OVERWRITE.



SET FLOW-CONTROL {DTR/CD, NONE, RTS/CTS, XON/XOFF}
    Normally XON/XOFF for full duplex flow control.  Should be set to NONE if
    the other system cannot do Xon/Xoff flow control, or if you have issued a
    SET HANDSHAKE command.  If set to XON/XOFF, then HANDSHAKE should be set to
    NONE.  This setting applies during both terminal connection and file
    transfer.  Warning: This command may have no effect on certain UNIX
    systems, where Kermit puts the communication line into "rawmode" and
    rawmode precludes flow control.


    The DTR/CD and RTS/CTS options are two kinds of "hardware flow control",
    using special wires (other than the data wires) in the connector.  These
    forms of flow control (especially RTS/CTS) are especially useful with
    high-speed modems and similar devices.  But these options are only
    available in those versions of C-Kermit whose underlying operating system
    supports them.


    Certain versions of UNIX, such as that on the NeXT, provide RTS/CTS flow
    control in a different way, namely in the device driver.  For example,
    /dev/cua is the first dialout port on the NeXT without RTS/CTS flow
    control, and /dev/cufa is the same port, but with built-in RTS/CTS flow
    control.




SET HANDSHAKE {XON, XOFF, CR, LF, BELL, ESC, NONE}
    Normally NONE.  Otherwise, half-duplex communication line turnaround
    handshaking is done during file transfer, which means C-Kermit will not
    reply to a packet until it has received the indicated handshake character
    or has timed out waiting for it; the handshake setting applies only during
    file transfer.  If you SET HANDSHAKE to other than NONE, then FLOW should
    be set to NONE.


SET HOST name
    For communicating over a network rather than a terminal device.  Presently
    supported only for Berkeley-based or other UNIX implementations using the
    socket interface to a TCP/IP network, for VAX/VMS with the TGV MultiNet
    TCP/IP package, and for SunLink X.25.  For TCP/IP networks, the name is the
    hostname or IP host number of a host on the network, optionally followed by
    a colon and an IP service number.  By default, C-Kermit connects to the
    telnet (virtual terminal server) socket on TCP/IP connections.  For X.25
    networks, the name is the X.121 address.


SET INCOMPLETE {DISCARD, KEEP}
    Disposition for incompletely received files.  If an incoming file is
    interrupted or an error occurs during transfer, the part that was received
    so far is normally discarded.  If you SET INCOMPLETE KEEP then partial
    files will be kept.


SET INPUT {CASE, ECHO, TIMEOUT-ACTION}
    Controls the behavior of the INPUT command.  See the section on script
    programming.


SET KEY n [ string ]
    Key mapping for CONNECT mode.  Tell Kermit that when you press the key
    whose code is n during CONNECT mode, it should substitute the string in its
    place.  The string is entered in the native character set of your computer,
    or you can use backslash codes.  The characters are subject to the same
    translation and shifting rules as the characters you would enter manually
    at the keyboard during CONNECT mode.  The code n must be a number between 0
    and 255 (higher numbers are possible on some computers, like OS/2, if
    Kermit knows how to read your computer's keyboard scan codes).  A key
    mapping for code n applies to all keys that produce this code, for example
    SET KEY \9 \27 assigns the code 27 (ESC) to the TAB key and to the CTRL-I
    key.  To find out a key's code, enter the SHOW KEY command, then press the
    key or key combination.  Entering the SET KEY for key n without specifying
    a string results in removing any previous key mapping for key n, i.e. n
    sends itself.  Key mappings do not apply to escape-character arguments.  If
    the escape character appears in a SET KEY string, it is treated as an
    ordinary data character, but if a key definition is exactly one character
    long, and that character is the escape character, it is treated as the
    escape character.


SET LANGUAGE {ICELANDIC, GERMAN, NORWEGIAN, RUSSIAN, ...}
    For use with international text file transfer.  If you tell Kermit what
    language a text file is written in, then Kermit might be able to apply
    certain transliteration tricks when translating between the file character
    set and the transfer character set.  See the section on international
    character sets.


SET LINE [terminal-device-name]
    The device name for the communication line to be used for file transfer and
    terminal connection, e.g. /dev/ttyi3 on a UNIX system or TXA0: on a VAX/VMS
    computer.  If you specify a device name, Kermit will be in local mode, and
    you should remember to issue any other necessary SET commands, such as SET
    SPEED (on UNIX, at least, the SET SPEED command is not strictly necessary
    -- Kermit will use the line's current speed, but you should use SET SPEED
    anyway, so that you be sure that speed you desire is actually being used).


    If you omit the device name, Kermit will revert to its default mode of
    operation.  If you specify the default device name (/dev/tty in UNIX, TT:
    in VMS), Kermit will enter remote mode (useful when logged in through the
    "back port" of a system normally used as a local-mode workstation).


    Whenever you give a SET LINE command, C-Kermit closes any currently open
    communication device before attempting to open the new one.  Therefore SET
    LINE is also useful for closing and hanging up a dialed connection.


    When UNIX Kermit enters local mode, it attempts to synchronize with other
    programs (like uucp) that use external communication lines so as to prevent
    two programs using the same line at once; before attempting to lock the
    specified line, it will close and unlock any external line that was
    previously in use.  If your system does not allow you to have write access
    to the uucp lock directory, then you will receive a message like "Sorry,
    access to lock denied."  In this case, you must ask your system
    administrator to ensure that uucp lockfiles are set up correctly and Kermit
    is installed correctly.  If Kermit were to use the external line without
    proper coordination with uucp (and even other copies of Kermit), then two
    or more users could find themselves using the same line at the same time,
    which would prevent all useful communication.


    If you SET LINE to a communication port that has a modem attached, and you
    have SET CARRIER ON, then the SET LINE command will not return until
    carrier appears on the device.  This is useful for setting up a Kermit
    program that other people can dial in to.  You can control the amount of
    time Kermit will wait for carrier using SET CARRIER ON n, where n is the
    number of seconds to wait for a connection before timing out.  You can also
    interrupt a blocked SET LINE command by typing Ctrl-C.


SET MACRO { ECHO, ERROR } { ON, OFF }
    Tells whether the individual commands that comprise a macro should be
    echoed on the screen during macro execution (normally they are not), and
    whether an error during macro execution should terminate the macro
    immediately (normally it does not).  See the section on script programming.


SET MODEM-DIALER name
    The type of modem  dialer on the communication line; the name identifies
    the modem type: DIRECT, HAYES, RACALVADIC, VENTEL, etc.  "Direct" indicates
    either there is no dialout modem, or that if the line requires carrier
    detection to open, then SET LINE will hang waiting for an incoming call.
    HAYES, VENTEL, and the others indicate that SET LINE will prepare for a
    subsequent DIAL command for the given dialer.  UNKNOWN means a modem is
    attached, but of an unknown or unsupported type.  Support for new dialers
    is added from time to time, so type SET MODEM ? for a list of those
    supported in your copy of Kermit.  Also see the description of the DIAL and
    SET DIAL commands.  NOTE: the SET MODEM command must be given before the
    SET LINE command if you plan to use the DIAL command.


SET NETWORK {TCP/IP, X.25}
    Select the type of network that is to be used for SET HOST connections.
    TCP/IP is presently available for UNIX systems that support the Berkeley
    sockets library (such as BSD-based UNIXes, HP-UX, Xenix with Excelan
    TCP/IP) and for VAX/VMS with the TGV MultiNet library.  X.25 is available
    only for SUNs with the SunLink product (see section on X.25 support).


SET PAD
    (See X.25 section)


SET PARITY {EVEN, ODD, MARK, SPACE, NONE}
    Specify character parity for use in packets and terminal connection,
    normally NONE.  If other than NONE, C-Kermit will seek to use the 8th-bit
    prefixing mechanism for transferring 8-bit data, which can be used
    successfully only if the other Kermit agrees during the automatic feature
    negotiation phase; if not, 8-bit data cannot be successfully transferred.
    In Berkeley-based UNIX implementations, if you SET PARITY to other than
    NONE, this will also enable Xon/Xoff flow control during file transfer if
    FLOW is set to XON/XOFF; otherwise, flow control is not done (because the
    communication line must be opened in "raw mode" for 8-bit data, which
    precludes the use of Xon/Xoff flow control in Berkeley UNIX).


SET PROMPT [text]
    The given text will be substituted for "C-Kermit>" as this program's
    prompt.  If the text is omitted, the prompt will revert to "C-Kermit>".  If
    the text is enclosed in { curly braces }, the braces are stripped and any
    leading and trailing blanks are retained.  The text may contain backslash
    codes.


SET QUIET {ON, OFF}
    Normally OFF.  Various informational messages are issued by the user
    interface.  ON suppresses these messages (but not error messages).
    Equivalent to '-q' on the command line.


SET RECEIVE parameter value
    (See SET SEND.)


SET RETRY n
    Specify the maximum number of times a particular packet can be
    retransmitted (because of timeout or transmission errors) before Kermit
    gives up and declares the file transfer a failure.


SET {SEND, RECEIVE} parameter value
    These commands are used to modify the normal formats and procedures used by
    the Kermit file transfer protocol.  Normally they are not necessary, but
    they can be used to overcome unusual obstacles, or to improve Kermit's
    performance.


    The SET RECEIVE command lets you tell the other Kermit how it should format
    the packets it sends to you.  Give SET RECEIVE commands to the Kermit that
    is going to receive files.  If you plan to transfer files in both
    directions, give SET RECEIVE commands to both Kermits.


    The SET SEND command rarely needs to be used.  It is for overriding what
    the the other Kermit requests, and should be necessary only if you cannot
    use a SET RECEIVE command to modify the parameter in question on the
    receiving Kermit.

    SET {RECEIVE, SEND} END-OF-PACKET cc
        Specifies the control character that marks the end of a Kermit packet.
        Normally 13 (carriage return), which most Kermit implementations
        require.


    SET {RECEIVE, SEND} PACKET-LENGTH n
        Specify the maximum packet length, normally 90.  Shorter packet lengths
        can be useful on noisy lines, or with systems or front ends or networks
        that have small buffers.  The shorter the packet, the higher the
        overhead, but the lower the chance of a packet being corrupted by
        noise, and the less time to retransmit corrupted packets.  If you
        request a length greater than 94, "long packets" are used, which is a
        feature that not all other Kermit programs support (most popular ones
        do).  C-Kermit can send and receive packets up to about 2000 characters
        in length.  If you use longer packets, you should also request a
        stronger error checking method (see SET BLOCK-CHECK).  SET SEND
        PACKET-LENGTH overrides the value requested by the other Kermit during
        protocol initiation unless the other Kermit requests a shorter length.


    SET {RECEIVE, SEND} PAD-CHARACTER cc
        SET RECEIVE PAD-CHARACTER allows C-Kermit to request the other Kermit
        to use cc as a pad character.  Default cc is NUL, ASCII 0.  C-Kermit
        normally does not need to have incoming packets preceded with pad
        characters.  SET SEND PAD-CHARACTER designates a character to send
        before each packet.  Normally, none is sent.  Outbound padding is
        sometimes necessary for communicating with slow half duplex systems
        that provide no other means of line turnaround control.  It can also be
        used to send special characters to communications equipment that needs
        to be put in "transparent" or "no echo" mode, when this can be
        accomplished in by feeding it a certain control character.


    SET {RECEIVE, SEND} PADDING n
        How many pad characters to request or send, normally 0.


    SET {RECEIVE, SEND} START-OF-PACKET number
        The normal Kermit packet prefix is Control-A (1); this command changes
        the prefix C-Kermit puts on outbound packets.  The only reasons this
        should ever be changed would be: Some piece of equipment somewhere
        between the two Kermit programs will not pass through a Control-A; or,
        some piece of of equipment similarly placed is echoing its input.  In
        the latter case, the recipient of such an echo can change the packet
        prefix for outbound packets to be different from that of arriving
        packets, so that the echoed packets will be ignored.  The opposite
        Kermit must also be told to change the prefix for its inbound packets
        (use SET RECEIVE START on one Kermit and SET SEND START on the other).


    SET {RECEIVE, SEND} TIMEOUT n
        Normally, each Kermit partner sets its packet timeout interval based on
        what the opposite Kermit requests.  SET RECEIVE TIMEOUT allows you to
        override the normal procedure and specify a timeout interval for
        C-Kermit to use when waiting for packets from the other Kermit.  If you
        specify 0, then no timeouts will occur, and C-Kermit will wait forever
        for expected packets to arrive (relying on the other Kermit to provide
        the timeout function).  SET SEND TIMEOUT specifies the number of
        seconds to wait for a packet before timing it out and retransmitting or
        requesting retransmission.



SET SCRIPT ECHO {ON, OFF}
    Tell whether the SCRIPT command should echo its interactions with the
    remote host on your screen.  ON by default.


SET SERVER DISPLAY {ON, OFF}
    Specify whether C-Kermit, when in server mode, should put a file transfer
    display on the screen when it is in local mode.  Normally OFF.


SET SERVER TIMEOUT n
    Specify the time interval n in seconds for the C-Kermit server to send NAK
    packets while waiting for a command packet.  These NAKs are intended to
    break deadlocks in case a client Kermit that cannot time out sends a
    command packet which is lost.  However, the server command-wait NAKs can
    interfere with originate/answer devices that are to be used for answering.
    For example, you can run a C-Kermit server on a modem line that normally
    dials out, so that people can dial in to it and give Kermit commands.
    While waiting for the phone call to come, the server NAKs might "wake up"
    the modem and put it into originate mode, preventing the incoming call from
    being answered.


SET SESSION-LOG { BINARY, TEXT }
    Specify how the session log is to be written.  TEXT is the default, meaning
    that lines are written using the convention of the local system; for
    example, UNIX session logs will have carriage returns (and certain other
    extraneous characters like NUL) omitted.  BINARY means to record all
    characters in the session log.


SET SPEED n
    The transmission speed in bits per second ("baud rate") for the
    communication line specified in SET LINE (but not SET HOST).  This command
    cannot be used to change the speed of your own console terminal.  Some
    computers are set up in such a way that you must give this command after a
    SET LINE command before you can use the line.  Type SET SPEED ? to see what
    speeds are available.  Use speeds greater than 9600 with caution, since
    they are not necessarily supported by the communication devices on your
    computer or the other computer, or the communication path between them.


SET SUSPEND { OFF, ON }
    (UNIX only) On UNIX versions that support job control, C-Kermit can
    normally be put in the background by typing the suspend character (usually
    Ctrl-\), or giving C-Kermit the SUSPEND (or Z) command, or by using the Z
    connect-mode escape.  SET SUSPEND OFF disables this feature.  This is
    useful when suspending doesn't work right (e.g. on certain UNIX
    implementations that have bugs) or when you are running Kermit under the
    Bourne shell.


SET TAKE { ECHO, ERROR } { ON, OFF }
    SET TAKE ECHO tells whether commands from a TAKE file are displayed on the
    screen as they are executed (normally they are not).  SET TAKE ERROR
    controls whether execution of a TAKE command file should be terminated if
    an error occurs (normally it is not).


SET TERMINAL parameter value
    Used for specifying terminal parameters.

    SET TERMINAL BYTESIZE { 7, 8 }
        tells the character size to be used on the communication line between
        the local C-Kermit and the remote Kermit during terminal emulation
        (C-Kermit CONNECT command).  It's 7 by default, which means that the
        high-order (8th) bit is stripped from each incoming and outgoing
        character.  Use 8 for 8-bit character sets like ISO Latin Alphabet 1,
        but this will work only if the connection really is 8-bits no-parity.
        Compare with SET COMMAND BYTESIZE.


    SET TERMINAL CHARACTER SET <remote-set> [ <local-set> ]
        For use during CONNECT.  Specify the character set that is being sent
        to C-Kermit by the remote computer, and specify which local character
        set to translate it into.  If the local character set is omitted, the
        current file character set is used.  The choices for the character sets
        are the same as for C-Kermit's file character sets (see SET FILE
        CHARACTER-SET).  SET TERMINAL CHARACTER-SET TRANSPARENT (which is
        Kermit's startup default) means no translation is done.  Equivalently,
        no translation is done if the local and remote sets are specified to be
        the same.  When they are different, translation goes through the Latin
        Alphabet 1 unless the local character set is Cyrillic-based in which
        case it goes through the Latin/Cyrillic Alphabet.  Kanji terminal
        character-sets are not supported.


    SET TERMINAL LOCKING-SHIFT { OFF, ON }
        Tells C-Kermit whether to use Shift-In/Shift-Out (Ctrl-O and Ctrl-N) to
        switch between 7-bit and 8-bit characters during CONNECT.  Applies to
        the Kermit-to-remote part of the connection only, and it applies to
        both the characters you type and to those Kermit receives from the
        remote.  OFF by default.


    SET TERMINAL NEWLINE { ON, OFF }
        OFF is the default.  When ON, Kermit sends CRLF whenever you type CR
        during terminal emulation.


    SET TERMINAL TYPE { VT100, TEK }
        (OS/2 C-Kermit only) Select the type of terminal to emulate.

Terminal parameters can be displayed with the SHOW TERMINAL command.


SET TRANSFER CHARACTER-SET name
    Tells what character set should be used for file data within Kermit packets
    during transfer of text files.  The choices are:

    TRANSPARENT
        Don't translate characters at all.


    ASCII
        Means to use the 7-bit ASCII (American Standard Code for Information
        Interchange) character set.  If the local file character set contains
        characters that do not occur in ASCII (like accented letters),
        represent them in ASCII the best way possible.


    CYRILLIC-ISO
        Means to use the ISO 8859-5 Latin/Cyrillic Alphabet, which is capable
        of representing Russian, Ukrainian, Bulgarian, Serbian, etc.


    LATIN1
        Means to use ISO 8859 Latin Alphabet 1, which is capable of
        representing most western European languages (English, German, Spanish,
        Dutch, Italian, Norwegian, Danish, Swedish, Portuguese, etc).


    JAPANESE-EUC
        Means to use Japanese Extended UNIX Code, which is a mixture of 7-bit
        Roman (Japanese ISO 646, similar to ASCII), single-byte Katakana, and
        double-byte JIS X 0208 Kanji.



SET TRANSMIT parameter value
    Controls the behavior of the TRANSMIT command, used for uploading files to
    computers that don't have Kermit programs.  See TRANSMIT.  The parameters
    are:

    ECHO { OFF, ON }
        Controls whether the characters that are sent to the other computer are
        also displayed on your screen.  The default is ON.


    EOF string
        String to send after sending the file, for example SET TRANSMIT EOF \4
        to send a Ctrl-D.


    FILL character
        ASCII value of character to insert into blank lines.  Some computers
        ignore blank lines, others might terminate the upload when they receive
        a blank line.  Use this command to insert a character, such as space
        (32) or X (88), in any blank line.


    LINEFEED { ON, OFF }
        Transmit linefeed as well as carriage return at the end of each line.
        Normally, only CR is sent.


    LOCKING-SHIFT { ON, OFF }
        Whether to send the locking-shift characters SO (Ctrl-N) and SI
        (Ctrl-O) around 8-bit characters when transmitting and PARITY is not
        NONE.


    PAUSE n
        Number of milliseconds (1000 milliseconds = 1 second) to pause after
        sending each line of a text file, or each character of a binary file
        (according to SET FILE TYPE).  Maximum 1000, default 0.


    PROMPT n
        ASCII value of character to look for from host before sending next
        line, normally LF (10), in text mode only; 0 means not to wait for any
        responses from the host -- just send all the characters in a steady
        stream.  This command has no effect in binary mode (i.e. when FILE TYPE
        is set to BINARY).

Synonym: SET XMIT.


SET UNKNOWN-CHAR-SET { DISCARD, KEEP }
    Tells what to do if a file arrives whose Attribute packet announces a
    transfer character set unknown to C-Kermit.


SET WILDCARD-EXPANSION { KERMIT, SHELL }
    (UNIX only) Tells who should expand wildcard characters in SEND and similar
    commands: KERMIT (the default) or the user's preferred UNIX shell (such as
    sh, csh, or ksh).


SET WINDOW n
    Select a window size.  This refers to Kermit's sliding window packet
    transport protocol.  Normally, Kermit sends a packet, waits for the reply,
    then sends the next packet, and so on.  This is called "stop and wait"
    operation, corresponding to a window size of 1, and is supported by all
    Kermit programs.  If you select a window size greater than 1, and if the
    other Kermit supports sliding windows, then multiple packets (up to the
    window size) can be sent before any replies are required.  This allows file
    transfer to operate efficiently over connections that have long delays,
    like over public data networks or through satellites.


    With a sufficiently large window size, transmission can be continuous with
    no pauses or delays.  The maximum window size is 31, but sizes greater than
    5 or 10 are rarely necessary.


    Sliding windows may be used in conjunction with long packets, but the
    maximum length for packets decreases with increasing window size.


    Kermit uses the "selective retransmission" technique, so that if packets
    are damaged during sliding windows transfers, only the damaged packets are
    retransmitted.


SET X.25
    (See X.25 section)


The SHOW Command

Syntax: SHOW category

The SHOW command with the default argument of "parameters" displays the values
of most of the SET parameters described above.  If you type a category name
after SHOW, then a more detailed report of parameters within the named category
are displayed, for example SHOW COMMUNICATIONS, SHOW PROTOCOL.  Type SHOW ? to
see a list of the available categories.


1.12. Backslash Notation

\ (backslash) in any command means that what follows is not ordinary text, but
rather a code, variable, or function whose value is to be substituted into the
command at that point.  The character after the backslash identifies which kind
of quantity this is:

    % A user-defined simple (scalar) variable
    & an array reference
    $ an environment variable
    v (or V) a built-in variable
    f (or F) a function
    d (or D) a decimal (base 10) number
    o (or O) an octal (base 8) number
    x (or X) a hexadecimal (base 16) number
    \ the backslash character itself
    \b
      (or \B) the BREAK signal (OUTPUT command only)
    \l
      (or \L) a Long BREAK signal (OUTPUT command only)
    a decimal digit
      a 1-3 digit decimal number.
    anything else
      The following character is taken literally.

Variables, arrays, functions, etc, are explained in the next section.  Numbers
can be expressed in backslash notation in the following ways:

\{...}
    A grouped number, braces discarded, e.g. \{17}5 is not the same as \175.


\nnn
    (1-3 decimal digits) replaced by binary number 0-255, e.g.  \13 represents
    carriage return (ASCII 13).


\dnnn or \Dnnn - Same as \nnn


\onnn or \Onnn (1-3 octal digits) replaced by binary number 0-255.


\xnn or \Xnn (2 hexadecimal digits) replaced by binary number 0-255.

Numbers expressed in backslash notation are typically used to express
nonprintable ASCII characters within character strings, or in commands that
want you to enter the ASCII value of a character.  Examples:

    echo \7Wake up!\7            ; A message with beeps
    echo \27[H\27[J              ; VT100 clear-screen sequence
    set pad-character \o177      ; The ASCII character DEL


1.13. Macros, Variables, and Script Programming

C-Kermit's script programming language is based upon that of MS-DOS Kermit, and
it is in most ways upwards compatible with it, meaning that many MS-DOS Kermit
script programs (or TAKE files in general) will work in C-Kermit with little or
no modification.  C-Kermit also has a SCRIPT command that provides a terse but
cryptic shorthand for automating certain kinds of interactive operations (see
Section 1.14).


1.13.1. Variables

A variable name is of the form \%i, where i is a single letter or digit.
Letter-variables are different from digit-variables, which are used as macro
parameters.  The alphabetic case of a letter-variable doesn't matter:  \%a is
the same variable as \%A.

All variables have character strings as values.  A variable is considered to
exist if its value is a string of at least one character in length, otherwise
it is "undefined" and does not exist.

A value is given to a variable using the DEFINE or ASSIGN command:

DEFINE name [ text ]
    The named variable (or macro, see below) is created, with text as a value.
    If a macro or variable of the given name already exists, its definition is
    replaced with the new one.  The given text is copied into the definition
    literally.  If it contains any variable names, functions references, etc,
    these are simply copied, rather than evaluated.


ASSIGN name text
    The text is evaluated, and then the named variable or macro's value is set
    to the evaluated text.  This differs from DEFINE, which does not evaluate
    the text, but rather copies it literally.  The distinction between ASSIGN
    and DEFINE doesn't matter unless the text contains variable names.  With
    ASSIGN, the contents of the variable is copied, whereas with DEFINE, the
    name of the variable is copied.

To illustrate the difference between DEFINE and ASSIGN:

    def \%a Monday
    def \%b Today is \%a
    assign \%c Today is \%a
    def \%a Tuesday
    echo \%b
    echo \%c

The definition of \%b is "Today is \%a", so that whenever the value of \%a
changes, so does the value of \%b.  The definition of \%c, however, is fixed as
"Today is Monday", because "Monday" was the value of \%a at the time that \%c
was assigned.

A variable can be used in any Kermit command simply by referring to its name:

    echo \%a

and variables can be undefined by DEFINEing or ASSIGNing nothing to them, for
example:

    define \%a

You can define variables with long names, too:

    define telephone-number 7654321

But you have to refer to them in a special way, \m(name), e.g.:

    echo \m(telephone-number)

A special kind of variable is called an array.  This is simply a list, in which
each element has a number.  An array reference looks like \&a[i].  The \& means
this is an array element rather than a simple variable, the letter tells which
array it is (a, b, c, ..., z), and the brackets enclose an index which tells
which member of the array is being referred to: 1, 2, 3, etc.  The index can be
a number, or it can be a variable or function (even another array element) that
has a numeric value.  Array indices must be (or evaluate to) zero or greater.

Arrays have to be declared before you can use them, so Kermit will know how big
the array is and can create storage for it.  The command is DECLARE, for
example:

    DECLARE \&A[100]

This tells Kermit to create an array called \&a with 100 elements.  Once an
array is declared, its elements can be used just like simple variables:

    DEFINE \&A[3] Tuesday

An entire array can be destroyed like this:

    DECLARE \&A[0]

If you refer to an element of an array that is not declared, the reference is
replaced by the empty string.

The array \&@[] is predeclared.  It contains the command line that the Kermit
program was invoked with, one word per array element.  The number of elements
in the array is given in the built-in variable \v(args) (described later).
Example:

    $ kermit -p e -b 3

Here \&@[0] is the Kermit program's file specification, like
/usr/local/bin/kermit; \&@[1] is -p, \&@[2] is e, and so on.

The simple variables \%a..\%z and the arrays \&a[]..\&z[] are all global, which
means they can be referenced from anywhere in your script program, including
from within a TAKE file or macro.

You can list the names and values of all existing global simple variables with
the SHOW GLOBALS command, and you can list the names and dimensions of all
declared arrays with SHOW ARRAYS.


1.13.2. Macros

A Kermit macro is a list of one or more Kermit commands that can be referred to
by a single name.  Like variables, macros are created by the DEFINE (or ASSIGN)
command:

    define ibm set parity mark, set duplex half, set handsh xon

and unlike variables, macros do not have weird-looking names; macro names can
be ordinary words.

Once a macro is defined, you can execute all of its commands simply by typing
the macro's name:

    C-Kermit>ibm

If you have defined a macro that has the same name as one of Kermit's built-in
commands, you will have to insert the word DO before the name in order to
execute the macro rather than the built-in command:

    C-Kermit>do ibm

(you can also use the word DO to invoke any macro).  In these examples, "IBM"
and "DO IBM" are the macro invocations.  If you follow a macro invocation by
one or more "words" (a word is a sequence of characters delimited by spaces, or
else at the end of a line), then each of these words is assigned to a
digit-variable that is accessible to the commands within the macro definition.
These trailing "words" are called the macro parameters.  The first parameter is
assigned to \%1, the second to \%2, and so on, up to a maximum of nine.  The
variable \%0 contains the name of the macro:

    define demo echo \%0: \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9
    demo this is a test of macro argument passing

Variables that do not have corresponding parameters are undefined (empty).  The
number of arguments passed to the macro is available in the named variable
\v(argc)(which, for compatibility with MS-DOS Kermit, may also be referred to
simply as ARGC, but only within IF conditions.)  Macro parameters are local to
the macro they are passed to.  If macro A invokes macro B, macro B gets its own
set of parameters, which are separate from macro A's, so that macro A still has
its own parameters available after macro B has completed.  The variables
\%0..\%9 may be used as global variables at "top level", when no macros are
active, by assigning values to them in the normal way.  To demonstrate:

    define xx echo \%1, yy Sneezy, echo \%1
    define yy echo \%1, zz Grumpy, echo \%1
    define zz echo \%1
    xx Sleepy

Try this, and you'll see how the value of \%1 is saved and restored at each
level.

Macro parameter words may be grouped into single parameters by enclosing them
in braces.  Try the following example to see how this works:

    define msg echo \%0: \%1
    msg this is another test of macro argument passing
    msg {this is yet another test of macro argument passing}

You can have a macro list its arguments on your screen by including the command
SHOW ARGUMENTS within the macro definition.

You can list the names and definitions of all existing macros with the SHOW
MACROS command.  If you include a name, as in "SHOW MACROS FOO", it will list
the definition(s) of only those macros whose names start with the character(s)
you have specified.

If you define a macro named ON_EXIT, it will be executed automatically when the
Kermit program exits.


1.13.3. Named Variables

Built-in named variables are read-only, you cannot change them.  Their names
are of the form \v(name), in which the v can be lower or uppercase, and the
parentheses are required around the variable name.  If you refer to a named
variable that does not exist, it will be evaluated as the empty (zero-length)
string.  C-Kermit's variables are:

    \v(argc)
        number of arguments passed to currently active macro.


    \v(args)
        number of arguments passed to the program on the command line.  The
        program argument vector is assigned to the array \&@[].


    \v(count)
        current value of COUNT (loop control via SET COUNT, IF COUNT).


    \v(cpu)
        CPU hardware type, if known, otherwise "unknown".


    \v(date)
        current date in dd mmm yyyy format (e.g. 8 Feb 1990 or 10 Nov 1990)


    \v(directory)
        current device and/or directory.


    \v(filespec)
        file specification from most recent SEND, MSEND, or GET command, or the
        name of the file most recently received.


    \v(fsize)
        size of last file transferred.


    \v(home)
        user's home (login) directory name.


    \v(host)
        computer hostname.


    \v(input)
        current INPUT buffer contents.


    \v(line)
        current communication device or network host.


    \v(ndate)
        current date in numeric format, e.g. 19901225.


    \v(ntime)
        current time in seconds since midnight, 0 through 86399.


    \v(platform)
        name specific machine or environment C-Kermit was built for.


    \v(return)
        Value of most recent RETURN command.


    \v(speed)
        Transmission speed of current communication device, if known.  (A
        spurious value of 38400 might be reported for pseudoterminals.)


    \v(status)
        0 if the previous command succeeded, nonzero if it failed.


    \v(system)
        name of generic operating system C-Kermit was built for, such as UNIX
        or VMS.


    \v(tfsize)
        total size of all files in the last group of files that was
        transferred.


    \v(time)
        current time in hh:mm:ss 24-hour clock format (e.g. 13:45:23).


    \v(ttyfd)
        file descriptor of communication device (UNIX only).


    \v(version)
        numeric version number of C-Kermit.

You can use these variables in any Kermit command where their values would make
sense:

    echo It is \v(time) o'clock on \v(date)

A \v-variable's name can be abbreviated, as long as the abbreviation is enough
to distinguish it from all the other built-in variable names:  \v(dir),
\v(ver), etc.

You can get a listing of Kermit's built-in variables and their values with the
SHOW VARIABLES command.


1.13.4. Built-in Functions

Built-in functions are of the form \fname(args).  The F and the name can be
upper or lower case.  The args are a comma-separated list of arguments.  The
function reference is replaced by its value.  For example:

    define \%a ABC123XYZ
    define \%b ...\Flower(\%a)...

results in a value of ...abc123xyz... for \%b.

The names of built-in functions and variables can be abbreviated to their
minimum unique length, for example \feval(1+1), \v(dir), etc.  C-Kermit's
functions include string-oriented functions that return a string:

    \Fliteral(arg)
        Copies its argument literally, without any evaluation.


    \Fcharacter(arg)
        Returns the single character corresponding to its argument, which must
        be numeric.  For example, \fchar(65) is 'A', \fchar(193) is A-acute (in
        the Latin-1).  If you give a negative number or a number larger than
        255, only the low-order 8 bits are used.


    \Fsubstr(arg1,arg2,arg3)
        Substring of the string arg1 starting at position arg2, of length arg3.
        arg2 and arg3 must be numbers or variables that have numeric values.
        Example:

            echo \fsubst(hello there,7,5)

        extracts the word "there".  The following is equivalent:

            define \%a hello there
            define \%b 7
            define \%c 5
            echo \fsubst(\%a,\%b,\%c)



    \Flower(arg)
        Converts all uppercase letters in its argument to lowercase, for
        example:

            define \%a FINE
            echo This is a \flower(\%a Mess).

        prints "This is a fine mess."


    \Fupper(arg)
        Converts all lowercase letters in its argument to uppercase.


    \Freverse(arg)
        Reverses the order of the characters in its argument, for example
        \frev(mupeen) is neepum.


    \Frepeat(arg1,arg2)
        Repeats the first argument the number of times given by the second
        argument, for example:

            echo +\frep(-+,10)

        produces +-+-+-+-+-+-+-+-+-+-+.


    \Flpad(text,n,c)
        Left-pads the text out to length n with character c.  If c is omitted,
        blank (space) is used.


    \Frpad(text,n,c)
        Right-pads the text out to length n with character c.  If c is omitted,
        blank (space) is used.


    \Fexecute(macroname macro-args)
        Execute the named macro with the given parameters (if any), return the
        macro's RETURN value if any (see RETURN).


    \Fcontents(variable-name)
        Returns the current definition (contents) of a variable.  If the
        definition includes variable names or function references, these are
        copied literally, without evaluation.


    \Fdefinition(macro-name)
        Returns the literal definition of the named macro.

Here are the string functions that return a number:

    \Flength(arg)
        Returns the length of the argument string.


    \Findex(arg1,arg2,arg3)
        Returns the position of the first occurrence string arg1 in string
        arg2, starting at position arg3.  If arg3 is omitted, then starting at
        the beginning.

File functions:

    \Ffiles(filespec)
        Returns the number of files that match the given file specification,
        for example \ffiles(ck*.c).


    \Fnextfile()
        Returns the next filename that matches the \Ffiles() file
        specification.  Use this in a counted loop (see below) after executing
        \Ffiles().

Integer arithmetic functions:

    \Fmax(arg1,arg2)
        Returns the maximum of its two numeric arguments.


    \Fmin(arg1,arg2)
        Returns the minimum of its two numeric arguments.


    \Feval(expression)
        Evaluates the given arithmetic expression.  The operands of the
        expression can be numeric strings or variables, or functions that
        evaluate to numeric strings.  The precedence is the normal, intuitive
        algebraic (or programming) precedence, and can be altered by the use of
        parentheses, which have higher precedence than any other operator.
        Spaces may be used to separate operators from operands, but they are
        not required.

Table 1-1 shows the types of expressions accepted by \feval().

-------------------------------------------------------------------------------


    Operator  Fix   Precedence   Operation          Example

     (   )              1         Group             (\%a + 3) * (\%1-5)
       !      Post      2         Factorial         \%x! - (\%x-2)!

       ~      Pre       3         Logical NOT       ~\%n
       -      Pre       3         Negative          -\%n

       ^      In        4         Raise to power    2^\%p

       *      In        5         Multiply          \%c * 5
       /      In        5         Divide            \%c / 5
       %      In        5         Modulus           \%c % 5
       &      In        5         Logical AND       \%c & 5

       +      In        6         Add               \%t + \%u
       -      In        6         Subtract          27 - \%x
       |      In        6         Logical OR        \%z | 4
       #      In        6         Exclusive OR      \%z # 4
       @      In        6         Greatest Common   \%z @ 30
                                  Divisor

                   Table 1-1:  \feval() Arithmetic Functions

-------------------------------------------------------------------------------

You can list the names of Kermit's built-in functions with the SHOW FUNCTIONS
command.

Two Kermit commands are also available to perform simple arithmetic on
variables:

INCREMENT name [value]
    Add value to the named variable.  If value is omitted, add 1.  If the
    variable does not have a numeric value, this command has no effect.
    Examples: inc \%a, incr \%b 10.


DECREMENT name [value]
    Subtract value from the named variable.  If value is omitted, subtract 1.
    If the variable does not have a numeric value, this command has no effect.


1.13.5. Script Programming

Kermit's script programming language lets you write procedures, or programs,
that can include any Kermit command.  Variables and functions can be referenced
at practically any point in any command.  Control structures are provided for
decision making, transfer of control, looping, scoping of variables, and so
forth.  A script program can be a TAKE file, a macro, or any combination of the
two.

The basic idea of a script program is to automate tasks that you would normally
do "by hand" when interacting with another computer: dialing the modem,
negotiating through network boxes and front ends, logging in, etc etc.  You can
also write programs to manage local files, or to do anything that you could do
manually with Kermit.

To automate interaction with another computer, you need a replacement for the
CONNECT command.  This comes in two parts, an OUTPUT command that "types" what
you would type during CONNECT, and an INPUT command that reads the other
computer's responses, plus a couple related commands:

OUTPUT text
    Send the text to the other computer.  The text can be any combination of
    plain ordinary characters, backslash codes, variables, and functions.  To
    send a BREAK signal, include \\B in the OUTPUT string.  To send a Long
    BREAK signal, include \\L in the OUTPUT string.

INPUT timeout text
    Read responses from the other computer.  Wait up to timeout seconds for the
    specified text to appear.  If the text appears within the timeout interval,
    the command succeeds immediately.  Otherwise it fails.  The text can
    contain any combination of ordinary characters, backslash codes, variables,
    and functions.  If you want to include leading and/or trailing blanks in
    the INPUT text, surround it with braces, as in:

        input 10 {login: }

    INPUT can be interrupted with Ctrl-C, in which case it fails.

REINPUT timeout text
    Searches previous responses from the computer for the given text.  The
    timeout parameter is ignored.  The previous responses are stored in the
    INPUT buffer, which is 256 characters long, and which may also be accessed
    via the \v(input) variable.

ECHO [ text ]
    Display the text on the local screen, followed by a newline.  The text can
    contain any combination of backslash codes, variables, functions, etc.

CLEAR
    Clear any as-yet-unread characters from the communication device's input
    buffer.

PAUSE [ n ]
    Do nothing for the indicated number of seconds.  If a number is not given,
    pause for 1 second.  If anything is typed on the keyboard during the pause
    interval, "wake up".  PAUSE can be interrupted by typing Ctrl-C (or any
    other character), in which case it fails.

WAIT [ n [ { CD, CTS, DSR } ] ]
    Wait up to n seconds for the specified modem signals to appear on the
    currently selected communication device.  If you don't include any modem
    signal names, WAIT is equivalent to PAUSE.  If you include one or more
    signal names (separated by spaces), Kermit will wait for all of the
    specified signals to appear.  If they don't appear within the alloted time,
    or if the device does not have modem control, then the command will fail.
    You may interrupt the WAIT command by typing any character at the keyboard,
    in which case the command will fail.  The command will also fail if
    modem-signal support is not included in C-Kermit for your particular
    operating system version.  The modem signals are: CD (carrier detect), CTS
    (Clear To Send), and DSR (Data Set Ready).

Example:

    wait 10 cd dsr      ; Wait 5 seconds for CD and DSR.
    if success goto ok  ; Test the result.

WAIT can be interrupted by typing Ctrl-C (or any other character), in which
case it fails.

The behavior of the INPUT command can be controlled by SET INPUT:

SET [ INPUT ] CASE {IGNORE, OBSERVE}
    Tells whether alphabetic case matters when searching the remote computer's
    responses for the INPUT text.  This setting also affects C-Kermit's other
    string comparison operations, including IF EQUAL, IF LGT, etc (IF command
    described later).

SET INPUT ECHO { ON, OFF }
    Tells whether the characters read by the INPUT command should be echoed on
    the screen.

SET INPUT TIMEOUT-ACTION { PROCEED, QUIT }
    Tells whether the script program should continue or stop immediately if an
    INPUT command fails.

At this point Kermit needs a decision making mechanism to tell whether the
INPUT command succeeded or failed.  This is the IF command.  Note that IF can
be used after INPUT only if you SET INPUT TIMEOUT PROCEED.

IF [NOT] condition command
    If the condition is satisfied, execute the following Kermit command.  If
    the word NOT is included, execute the command if the condition is not
    satisfied.  Only one command may be given, and it must appear on the same
    line as the IF.

The IF command supports a wide variety of conditions.  These are:

    IF SUCCESS
        The previous command succeeded.


    IF FAILURE
        The previous command failed.


    IF DEFINED name
        The named variable or macro is defined.


    IF BACKGROUND
        Kermit is running in the background or with its standard input and
        output redirected.


    IF COUNT
        Subtract one from COUNT, execute the command if the result is greater
        than zero (see SET COUNT).


    IF EXIST filename
        The named file exists.


    IF NUMERIC variable
        The variable's value is numeric.


    IF EQUAL s1 s2
        s1 and s2 (character strings or variables) are equal.


    IF LLT s1 s2
        s1 is lexically (alphabetically) less than s2.  Use IF NOT LGT for
        less-than-or-equal.


    IF LGT s1 s1
        s1 is lexically (alphabetically) greater than s2.  Use IF NOT LLT for
        greater-than-or-equal.


    IF = n1 n2
        n1 and n2 (numbers or variables containing numbers) are equal.


    IF < n1 n2
        n1 is arithmetically less than n2. Use IF NOT > for less-than-or-equal.


    IF > n1 n2
        n1 is arithmetically greater than n2\n.  Use IF NOT < for greater-than-
        or-equal.

String comparisons in IF EQUAL, IF LGT, and IF LLT treat alphabetic case
according to SET INPUT CASE {IGNORE, OBSERVE}.  You can also use \fupper() and
\flower() to force caseless comparisons if INPUT CASE is set to OBSERVE.

Arithmetic comparisons work with numeric constants, variables and array
elements that evaluate to a numeric string, functions that return a numeric
value, and the special "MS-DOS Kermit compatibility" variables COUNT, VERSION,
and ARGC, which can only appear in this context.  Numeric strings are converted
to binary integers before comparison, and may be positive, zero, or negative.
Floating point ("real") numbers are not supported.

The IF command may be followed on the next line by an ELSE command, which is
executed if the IF condition is not true, and which is not executed if the IF
condition is true.  Example:

    IF < \%x 10 ECHO It's less
    ELSE echo It's not less

As in any programming language, it is desirable to be able to go to different
places in the program based on the decisions made by IF commands.  The command
for going-to is:

GOTO label
    Go to the command which follows the named label.

A label is a word beginning with a colon (:) on the left margin.  Example:

    IF < \%x 10 goto less
    echo It's not less
    goto fin
    :less
    ECHO It's less
    :fin

Several other commands are especially useful in conditional contexts, i.e. as
objects of IF commands:

STOP
    Stop executing the current script program (TAKE file or macro) and return
    immediately to C-Kermit prompt level (or, if Kermit was invoked with
    command-line action arguments, exit C-Kermit altogether).

END [ n ]
    Go "up" one command level.  Exit the currently executing macro or TAKE
    file, and return to the invoking TAKE file or macro.  Or, if the current
    TAKE file or macro was invoked from C-Kermit> prompt level, return to the
    prompt.  Or, if Kermit was invoked with command-line action arguments, exit
    C-Kermit.  If a value is given, it is used to set the SUCCESS flag (if the
    value is zero) or the FAILURE flag (if the value is nonzero).  You can use
    POP as a synonym for this command.

RETURN [value]
    For use within macros.  Just like END, except that a return value may be
    set.  This is for use with the \fexecute() function, which allows you to
    write user-defined functions.  For example:

        def sum if = \%1 1 return 1,-
          else return \feval(\%1 + \fexecute(sum \feval(\%1 - 1)))

    This function, called SUM, returns the sum of all the numbers from 1 to
    whatever number (1 or greater) it was called with, for example:

        echo \fexec(sum 5)

    prints the number 15.  Notice that this function calls itself; C-Kermit
    functions are allowed to do this.

Although the object command of an IF or ELSE statement may only be a single
command, that command is allowed to be a macro invocation or a TAKE command.
This provides a kind of statement grouping that can be used to avoid a lot of
confusing GOTOs.  A more flexible kind of statement grouping is available in
the XIF ("extended IF") command:

XIF condition { command-list } [ ELSE { command-list } ]
    In this extended form, braces are required to enclose a comma-separated
    list of one or more commands, and the ELSE clause is on the same line as
    the XIF.  Example:

        xif < \%x 10 {ech Less,def \%m 10} else {ec Not less,def \%m \%x}

    Here the appropriate message is echoed, depending on the value of \%x, and
    the minimum of \%x and 10 is assigned to the variable \%m.  Commands like
    this one can be broken onto multiple lines for clarity, but only if you use
    dash (or backslash) for line continuation:

        xif < \%x 10 { -
            echo Less, -
            def \%m 10 -
        } else { -
            echo Not less, -
            def \%m \%x -
        }

WARNING: RETURN or END statements should not be used within an XIF command.


Other Ways of Assigning Values to Variables

Sometimes it is desirable for a script program to interact with you as well as
with the remote computer.  For example, you should not store passwords on disk,
so you can't write script programs that contain them.  However, you can write
script programs that prompt you for your password.  This is done using the ASK
or ASKQ command:

ASK name prompt
    Print the prompt on the screen and wait for you to type a line of text
    (terminated by carriage return), and assign this line of text to the named
    variable (but without the carriage return), for example:

        ask \%p Password:
        output \%p\13

    The prompt may be enclosed in { curly braces } to retain leading and/or
    trailing spaces.

ASKQ name prompt
    Just like ASK, but it "asks quietly".  The characters you type do not echo.
    Especially useful for passwords.

GETOK text
Asks a "yes or no" question.  The text is the question.  Enclose it in curly
braces to preserve leading or trailing spaces.  If the user replies "Yes" or
"OK" (or any abbreviation of these), the SUCCESS flag is set (for IF SUCCESS).
If she replies "N" or "No", the FAILURE flag is set.

Now, with IF, branching, ASK, and so forth, we can add to our login script:

    define error echo Error: \%1, end   ; Error-handling macro.
    set input timeout proceed           ; Don't quit if INPUT fails.
    set input case ignore               ; Alphabetic case doesn't matter.
    set input echo off                  ; Don't need to watch.
    output \13                          ; Send carriage return (ASCII 13).
    input 5 login:                      ; Wait 5 secs for "login:" prompt.
    if fail error {No login prompt}     ; Give up if it doesn't come.
    output myuserid\13                  ; Send user ID followed by CR.
    input 5 password:                   ; Wait for password prompt.
    if fail error {No password prompt}  ; Give up if it doesn't come.
    ask \%p Password:                   ; Prompt user for password
    output \%p\13                       ; Send it, followed by CR
    input 30 $\32                       ; Wait for system prompt "$ "
    if fail error {No system prompt}    ; Give up if it doesn't come.
    connect                             ; Got it, connect.


Reading and Writing Local Files

It is also possible to assign data from local files to variables.  In fact,
C-Kermit includes an entire input and output system for local files and
commands:

OPEN mode filename
    For use with READ and WRITE commands.  Open the local file in the specified
    mode: READ, WRITE, or APPEND.  !READ and !WRITE mean to read from or write
    to a system command rather than a file.  Examples:

        OPEN READ oofa.txt
        OPEN !READ ls ck[uwc].[cwh]

    The first example reads lines from the file oofa.txt.  The second reads
    filenames from a UNIX directory listing; this gives you a way to select
    files using your UNIX shell's filename-matching metacharacters, which are
    more powerful than Kermit's built-in ones.

READ name
    The next line from the current OPEN READ or OPEN !READ file is assigned to
    the named variable, for example READ \%A.  If no more lines remain in the
    file, the command fails.

WRITE name text
    Writes the given text to the named log or file.  The text text may include
    backslash codes, and is not terminated by a newline unless you include the
    appropriate code.  The name parameter can be any of the following:

    DEBUG-LOG
    FILE (the OPEN WRITE, OPEN !WRITE, or OPEN APPEND file).
    PACKET-LOG
    SCREEN (just like ECHO except that WRITE does not supply a line terminator)
    SESSION-LOG
    TRANSACTION-LOG

CLOSE name
    Closes the named file.  A READ or !READ file is closed automatically when
    end-of-file (EOF) is encountered during a READ operation, but it does no
    harm to close it again.  WRITE, !WRITE, and APPEND files must be closed
    explicitly.  Examples: CLOSE READ, CLOSE WRITE.

A typical script program for reading and writing files might look like this:

    set take error off                  ; So EOF can be handled.
    open read foo                       ; Open input file "foo".
    open write bar                      ; Open output file "bar".
    def \%c 0                           ; Make a line counter.
    :loop                               ; Loop to read all lines.
    read \%a                            ; Read one line into \%a.
    if fail goto done                   ; Catch EOF this way.
    increment \%c                       ; Count the line.
    write file \%c. \fupp(\%a)\10       ; Format and write it.
    goto loop                           ; Go back and get more.
    :done
    close read                          ; Finished,
    close write                         ; close the files.
    echo All done.                      ; Print a message.

The previous example shows a loop, which is a common programming construct.  It
is always desirable to avoid infinite loops.  The READ example does this by
testing for end of file (EOF) with IF FAILURE.


Counted Loops

Kermit also provides for "finite", or counted, loops, in several varieties:

SET COUNT / IF COUNT
    Here a special variable, COUNT, is set.  The IF COUNT command decrements
    the count variable, and if the result is greater than zero, executes the
    object command:

        set count 5
        :loop
        echo \v(count)
        if count goto loop
        else echo Zero!

FOR variable iv fv step { command, command, ... }
    The FOR loop is controlled by a loop variable which is assigned an initial
    value (iv), gets tested against a final value (fv), and gets incremented by
    a step value.  If the step value is positive, the loop exits when the loop
    variable is greater than the final value.  If the step is negative, the
    loop exits when the variable becomes less than the final value.  Example
    (cute way to print the 9's times table):

        for \%i 0 9 1 { assign \%j \feval(9-\%i), echo \%i\%j }

    FOR loops can be nested:

        for \%i 1 5 1 { for \%j 5 \%i -1 { echo \%i:\%j } }

WHILE condition { command, command, ... }
    The commands are executed as long as the condition is true.  The conditions
    are the same as for the IF command.  Example:

        while not exist foo.bar { sleep 1 }

    This loop waits until file named foo.bar appears.

FOR and WHILE loops can be nested in any combination.  Both FOR and WHILE loops
may be exited or continued prematurely using the following commands:

BREAK
    Exit from the closest enclosing FOR or WHILE loop.

CONTINUE
    Begin the next iteration (if any) of the closest enclosing FOR or WHILE
    loop immediately.

WARNING: RETURN and END commands should not be used in the object commands of
FOR, WHILE, or XIF.

Here's a script program example that has nothing to do with data communication
or file transfer, but which illustrates the control structures of the script
language, the use of arrays, statement grouping, file i/o, etc:

    ; Kermit script program to read a file of numbers into an array,
    ; sort the array numerically, and display the sorted result.
    ;
    def \%d 100                   ; Allow up to 100 elements.
    dcl &a[\%d]                   ; Declare a 100-element array.
    set take error off            ; To handle EOF on READ.
    open read numbers.dat         ; Open this file for reading.

    ; Read each line into a separate array element
    ;
    echo Reading...
    for \%n 1 \%d 1 { -
        read \&a[\%n], -
        if fail break -
    }
    decr \%n                      ; Subtract one for read that failed.
                                  ; Check for too many lines.
    xif > \%n \%d { -
        echo Too many lines in file, -
        stop -
    }
    echo Array initialized: \%n elements, sorting...

    ; Sort the array using the (slow) "bubble sort" algorithm.
    ;
    assign \%m \feval(\%n-1)
    for \%i 1 \%m 1 { -
        for \%j \%i \%n 1 { -
            xif > \&a[\%i] \&a[\%j] { -
                assign \%t \&a[\%i], -
                assign \&a[\%i] \&a[\%j], -
                assign \&a[\%j] \%t -
            } -
        } -
    }

    ; Display the sorted array.
    ;
    echo sorted.
    for \%i 1 \%n 1 { echo \flpad(\%i,3). \flpad(\&a[\%i],5) }

1.14. The SCRIPT Command

The SCRIPT command allows connection and login sequences to be specified in a
single, cryptic line in the style of the UNIX uucp L.sys file.

Syntax: SCRIPT expect send [expect send] . . .

"expect" has the syntax: expect[-send-expect[-send-expect[...]]]

The SCRIPT command carries on a "canned dialog" with a remote system, in which
data is sent according to the remote system's responses.  The typical use is
for logging in to a remote system automatically.

A login script is a sequence of the form:

    expect send [expect send] . . .

where expect is a prompt or message to be issued by the remote site, and send
is the string (names, numbers, etc) to return, and expects are separated from
sends by spaces.  The send may also be the keyword EOT, to send Control-D, or
BREAK, to send a break signal.  Letters in sends may be prefixed by `~' to send
special characters, including:

    ~b  backspace
    ~s  space
    ~q  `?'(trapped by Kermit's command interpreter)
    ~n  linefeed
    ~r  carriage return
    ~t  tab
    ~'  single quote
    ~-  dash (hyphen)
    ~~  tilde itself
    ~"  double quote
    ~x  XON (Control-Q)
    ~c  don't append a carriage return
    ~o[o[o]]  octal representation of an ASCII character code
    ~d  delay approx 1/3 second during send
    ~w[d[d]]  wait specified interval during expect, then time out
    \\b send a BREAK signal

As with some UUCP systems, sent strings are followed by ~r unless they have a
~c.

Only the last 7 characters in each expect are matched.  A null expect, e.g. ~0
or two adjacent dashes, causes a short delay before proceeding to the next send
sequence.  A null expect always succeeds.

As with UUCP, if the expect string does not arrive, the script attempt fails.
If you expect that a sequence might not arrive, as with UUCP, conditional
sequences may be expressed in the form:

    -send-expect[-send-expect[...]]

where dashed sequences are followed as long as previous expects fail.  Timeouts
for expects can be specified using ~w; ~w with no arguments waits 15 seconds.

expect-send transactions can be easily be debugged by logging transactions.
This records all exchanges, both expected and actual.  The script execution
will also be logged in the session log, if that is activated.

Note that `\' characters in login scripts, as in any other C-Kermit interactive
commands, must be doubled up.  A line may be ended with a single `\' for
continuation.

Example one:

Using a modem, dial a UNIX host site.  Expect "login" (...gin), and if it
doesn't come, simply send a null string with a ~r.  (Some UNIXes require either
an EOT or a BREAK instead of the null sequence, depending on the particular
site's "logger" program.)  After providing user id and password, respond "x" to
a question-mark prompt, expect the Bourne shell "$" prompt (and send return if
it doesn't arrive).  Then cd to directory kermit, and run the program called
"wermit", entering the interactive connect state after wermit is loaded.

    set modem ventel
    set line /dev/tty77
    set baud 1200
    dial 9&5551212
    script gin:--gin:--gin: smith ssword: mysecret ~q x $--$ \
     cd~skermit $ wermit
    connect

Note that SET LINE is issued after SET MODEM, but before SET BAUD or other
line-related parameters.

Example two:

Using a modem, dial the Telenet network.  This network expects three returns
with slight delays between them.  These are sent following null expects.  The
single return is here sent as a null string, with a return appended by default.
Four returns are sent to be safe before looking for the prompt.  Then the
Telenet id and password are entered.  Then Telenet is instructed to connect to
a host site (c 12345).  The host has a data switch that asks "which system";
the script responds "myhost" (if the "which system" prompt doesn't appear, the
Telenet connect command is reissued).  The script waits for an "@" prompt from
the host, then sends the user ID ("joe") and password ("secret"), looks for
another "@" prompt, runs Kermit, and in response to the Kermit's prompt (which
ends in ">"), gives the commands "set parity even" and "server".  Files are
then exchanged.  The commands are in a take file; note the continuation of the
'script' command onto several lines using the `\' terminator.

    set modem hayes
    set line /dev/acu
    set speed 1200
    set parity mark
    dial 9,5551212
    script ~0 ~0 ~0 ~0 ~0 ~0 ~0 ~0 @--@--@ id~s\
    aa001122 = 002211 @ c~s12345 ystem-c~s12345-ystem \
    myhost @ joe~ssecret @ kermit > set~sparity~seven > server
    send some.stuff
    get some.otherstuff
    bye
    quit

Since these commands may be executed totally in the background, they can also
be scheduled.  A typical shell script, which might be scheduled by cron, would
be as follows (csh used for this example):

    #
    # Keep trying to dial and log onto remote host and exchange
    # files, wait 10 minutes before retrying if it fails.
    #
    cd someplace
    while ( 1 )
        kermit < ./tonight.cmd >> nightly.log &
        if ( ! $status ) break
        sleep 600
    end

File tonight.cmd might have two takes in it, for example, one to take a file
with the set modem, set line, set baud, dial, and script, and a second take of
a file with send/get commands for the remote server.  The last lines of
tonight.cmd should be BYE and QUIT.


1.15. Command Line Operation

A subset of Kermit's commands is available using UNIX-style command line
options, on operating systems that support passing of command-line options to
programs through the "argv, argc" mechanism.

The C-Kermit command line syntax mostly conforms to the Proposed Syntax
Standards for UNIX System Commands put forth by Kathy Hemenway and Helene
Armitage of AT&T Bell Laboratories in UNIX/World, Vol.1, No.3, 1984.  The rules
that apply are:

   - Command names must be between 2 and 9 characters ("kermit" is 6).
   - Command names must include lower case letters and digits only.
   - An option name is a single character.
   - Options are delimited by '-'.
   - Options with no arguments may be grouped (bundled) behind one
     delimiter.
   - Option-arguments cannot be optional.
   - Arguments immediately follow options, separated by whitespace.
   - The order of options does not matter.
   - '-' preceded and followed by whitespace means standard input.

A group of bundled options may end with an option that has an argument.

The following notation is used in command descriptions:

    fn  A file specification, possibly containing the "wildcard" characters `*'
        or `?' (`*' matches all character strings, `?'  matches any single
        character).


    fn1 A UNIX file specification which may not contain `*' or `?'.


    rfn A remote file specification in the remote system's own syntax, which
        may denote a single file or a group of files.


    rfn1
        A remote file specification which should denote only a single file.


    n   A decimal number between 0 and 94.


    c   A decimal number between 0 and 127 representing the value of an ASCII
        character.


    cc  A decimal number between 0 and 31, or else exactly 127, representing
        the value of an ASCII control character.


    [ ] Any field in square braces is optional.


    {x,y,z}
        Alternatives are listed in curly braces.

C-Kermit command line options may specify any combination of actions and
settings.  If C-Kermit is invoked with a command line that specifies no
actions, then it will issue a prompt and begin interactive dialog.  Action
options specify either protocol transactions or terminal connection.

An implicit TAKE command is executed upon your C-Kermit initialization file
when C-Kermit starts up, upon either interactive or command-line invocation.
This file may contain C-Kermit interactive-mode commands, which are explained
later.

In addition, if the first command line argument is the name of an existing
file, C-Kermit will read that file and execute Kermit interactive-mode commands
from it, in addition to (and after) your initialization file (if any).
Example:

    $ kermit cmdfile -b 3 -p m

In UNIX, this feature allows you to invoke C-Kermit by "running" a C-Kermit
command file, if its first line is of the form:

    #!/dir/kermit

That is, number sign followed by exclamation point, followed by the full file
specification of the Kermit program.  You must also give this file execute
permission:

    $ chmod +x cmdfile

Then you can run this file as if it were a program, and it will feed itself to
C-Kermit automatically:

    $ cmdfile

You can even include C-Kermit command line options:

    $ cmdfile -l /dev/ttyh8 -p e

If you want the shell prompt to return automatically at the end of this file,
include an EXIT command at the end of it.  Otherwise you will receive the
C-Kermit prompt when the file is finished.

Here are C-Kermit's command-line options:

    =   Ignore all command-line options that follow (but make them available to
        the user in the array \&@[]).


    -Y  (uppercase) Do not execute commands from the initialization file.


    -y fn
        Read commands from the specified file instead of the normal
        initialization file.


    -C "command, command, ..."
        Execute the interactive-mode commands after the initialization file (if
        any), the other command-line options (if any), and the command or
        application file (if any).  The command list must be enclosed in double
        quotes.  Example:

            kermit -C "set file type binary, set window 2"

        The commands in this list are assigned to a macro called cl_commands,
        so you can also execute them later during your session simply by typing
        the name of this macro:

            C-Kermit>cl_commands

        The -C option does is not considered an "action" option, even if the
        command list contains action commands, so if there are no other action
        commands among the command-line arguments, the C-Kermit prompt appears
        after the last command in the list is executed.  To defeat this
        behavior, include EXIT as the last command:

            kermit -C "echo \27[2J\27H, exit"



    -S  ("Stay") This option tells C-Kermit to issue its prompt and enter
        interactive command mode, even if the command-line options included
        action commands.

These are the file-transfer commands:

    -s fn
        Send the specified file or files.  If fn contains wildcard (meta)
        characters, the UNIX shell expands it into a list.  On non-UNIX
        systems, Kermit expands any wildcard characters.  fn may also be a list
        of files, as in:

            kermit -s ckcmai.c ckuker.h mail.txt

        If fn is '-' then kermit sends from standard input, which may come from
        a file:

            kermit -s - < foo.bar

        or a parallel process:

            ls -l | grep cmg | kermit -s -

        You cannot use this mechanism to send terminal typein.  If you want to
        send a file whose actual name is "-" you can precede it with a path
        name, as in

            kermit -s ./-



    -r  Receive a file or files.  Wait passively for files to arrive.


    -k  Receive (passively) a file or files, sending them to standard output.
        This option can be used in several ways:

        kermit -k
            Displays the incoming files on your screen; to be used only in
            "local mode" (see below).


        kermit -k > fn1
            Sends the incoming file or files to the named file, fn1.  If more
            than one file arrives, all are concatenated together into the
            single file fn1.


        kermit -k | command
            Pipes the incoming data (single or multiple files) to the indicated
            command, as in

                kermit -k | sort > sorted.stuff



    -a fn1
        If you have specified a file transfer option, you may give an alternate
        name for a single file with the -a ("as") option.  For example,

            kermit -s foo -a bar

        sends the file foo telling the receiver that its name is bar.  If more
        than one file arrives or is sent, only the first file is affected by
        the -a option:

            kermit -ra baz

        stores the first incoming file under the name baz.


    -x  Begin server operation.  May be used in either local or remote mode.

Before proceeding, a few words about remote and local operation are necessary.
C-Kermit is "local" if it is running on PC or workstation that you are using
directly, or if it is running on a multiuser system and transferring files over
an external communication line -- not your job's controlling terminal or
console.  C-Kermit is remote if it is running on a multiuser system and
transferring files over its own controlling terminal's communication line
(normally /dev/tty), connected to your PC or workstation.

If you are running C-Kermit on a PC, it is normally used in local mode, with
the "back port" designated for file transfer and terminal connection, and the
keyboard and screen available to control or interrupt the file transfer and to
display its status.  If you are running C-Kermit on a multiuser (timesharing)
system, it is in remote mode unless you explicitly point it at an external line
for file transfer or terminal connection.  The following command determines
whether C-Kermit is in local or remote mode:

    -l dev
        Line -- Specify a terminal line to use for file transfer and terminal
        connection, as in:

            kermit -l /dev/ttyi5

        You can also give an open file descriptor for a serial communication
        (tty) device.

When an external line is being used, you will also need some additional options
for successful communication with the remote system:

    -b n
        Bits per second -- Specify the transmission speed in bits per second
        ("baud rate") for the line given in the -l option, as in:

            kermit -l /dev/ttyi5 -b 9600

        This option should always be included with the -l option, since the
        speed of an external line is not necessarily what you expect.


    -p x
        Parity -- e,o,m,s,n (even, odd, mark, space, or none).  If parity is
        other than none, then Kermit's 8th-bit prefixing mechanism will be used
        for transferring 8-bit binary data, provided the opposite Kermit
        agrees.  The default parity is none.


    -t  Specifies half duplex, line turnaround with XON as the handshake
        character, used mainly for communicating with IBM mainframes in
        linemode.


    -mname
        Modem type -- hayes, penril, vadic, etc.  For a complete and up-to-date
        list, run C-Kermit interactively and type "set modem ?".  Note:  name
        must be given in lowercase, but can be abbreviated, e.g. "hay" for
        "hayes".

If you wish to use a network connection rather than a terminal line for
communication, use the following options rather -l:

    -j name
        Host -- Specify a network host name.  This option is currently
        supported for TCP/IP Telnet connections on Berkeley-based UNIX
        implementations only, and for VAX/VMS when equipped with TGV MultiNet
        TCP/IP.  The speed (-b) parameter does not apply to network
        connections.  The name can be an IP host name, an IP host number
        (containing dots), or either one of these followed by a colon and then
        a TCP service name or number.  It can also be just a number, in which
        case it is assumed to be a file descriptor for an open TCP/IP TELNET
        connection.


    -X address
        X.25 address -- Specify an X.25 network address.


    -Z number
        X.25 file descriptor -- Specify a file descriptor for an X.25
        connection that is already open.

The following commands may be used only with a C-Kermit which is in local mode.

    -g rfn
        Actively request a remote server to send the named file or files; rfn
        is a file specification in the remote host's own syntax.  If fn happens
        to contain any special shell characters, like space, '*', '[', '~',
        etc, these must be quoted, as in:

            kermit -g x\*.\?

        or:

            kermit -g "profile exec"



    -f  Send a 'finish' command to a remote server.


    -c  Establish a terminal connection over the specified or default
        communication line, before any protocol transaction takes place.  Get
        back to the local system by typing the escape character (normally
        Control-Backslash) followed by the letter 'c'.


    -n  Like -c, but after a protocol transaction takes place; -c and -n may
        both be used in the same command.  The use of -n and -c is illustrated
        below.

If the other Kermit is on a remote system, the -l and -b options should also be
included with the -r, -k, or -s options.

Several other command-line options are provided:

    -i  Specifies that files should be sent or received exactly "as is" with no
        conversions.  This option is necessary for transmitting binary files.
        It may also be used in UNIX-to-UNIX transfers (it must be given to both
        UNIX Kermit programs), where it will improve performance by
        circumventing the normal text-file conversions, and will allow mixture
        of text and binary files in a single file group.  But only use it if
        character-set translation is not needed.


    -w  Writeover -- An incoming file should write over any existing file of
        the same name.  Changes the default behavior, which is to back up the
        existing file before creating the new one.


    -e n
        Extended packet length -- Specify that C-Kermit is allowed to receive
        packets up to length n, where n may be between 10 and some large
        number, like 1000 or 2000, depending on the system.  The default
        maximum length for received packets is 90.  Packets longer than 94 will
        be used only if the other Kermit supports, and agrees to use, the "long
        packet" protocol extension, and if you request them.


    -v n
        Window size -- Specify that C-Kermit is allowed to send and receive
        files using a window size of n.  That is, up to n packets may be sent
        before acknowledgements are required.  This speeds up transfers in most
        situations, especially long distance network connections.  Default
        window size is 1, maximum is 32.  Sizes greater than 1 work only if the
        other Kermit supports this option.


    -q  Quiet -- Suppress screen update during file transfer, for instance to
        allow a file transfer to proceed in the background.


    -z  Force foreground mode: even if Kermit thinks it is running in the
        background, this will make it issue its normal prompts and messages.
        Example:

            kermit -z | vt100



    -d  Debug -- Record debugging information in the file debug.log in the
        current directory.  Use this option if you believe the program is
        misbehaving, and show the resulting log to your local Kermit
        maintainer.


    -h  Help -- Display a brief synopsis of the command line options.

The command line may contain no more than one protocol action option.

During transmission, files are encoded as follows:

   - Control characters are converted to prefixed printables.

   - Sequences of repeated characters are collapsed via repeat counts, if
     the other Kermit is also capable of repeated-character compression.
     This feature is negotiated automatically.

   - If parity is being used on the communication line, data characters
     with the 8th (parity) bit on are specially prefixed, provided the
     other Kermit is capable of 8th-bit prefixing; if not, 8-bit binary
     files cannot be successfully transferred.  This feature is negotiated
     if you give the -p option.

   - Conversion is done between UNIX newlines and carriage-return-linefeed
     sequences unless the -i option was specified.


Command Line Examples:


    kermit -l /dev/ttyi5 -b 1200 -cn -r

This command connects you to the system on the other end of ttyi5 at 1200 baud,
where you presumably log in and run Kermit with a SEND command.  After you
escape back, C-Kermit waits for a file (or files) to arrive.  When the file
transfer is completed, you are reconnected to the remote system so that you can
logout.


    kermit -l /dev/ttyi4 -b 1800 -cntp m -r -a foo

This command is like the preceding one, except the remote system in this case
uses half duplex communication with mark parity.  The first file that arrives
is stored under the name foo.


    kermit -l /dev/ttyi6 -b 9600 -c | tek

This example uses Kermit to connect your terminal to the system at the other
end of ttyi6.  The C-Kermit terminal connection does not provide any particular
terminal emulation, so C-Kermit's standard i/o is piped through a
(hypothetical) program called tek, which performs (say) Tektronix emulation.


    kermit -l /dev/ttyi6 -b 9600 -nf

This command would be used to shut down a remote server and then connect to the
remote system, in order to log out or to make further use of it.  The -n option
is invoked after -f (-c would have been invoked before).


    kermit -l /dev/ttyi6 -b 9600 -qg foo.\* &

This command causes C-Kermit to be invoked in the background, getting a group
of files from a remote server (note the quoting of the `*' character).  No
display occurs on the screen, and the keyboard is not sampled for interruption
commands.  This allows other work to be done while file transfers proceed in
the background.  UNIX only.


    kermit -l /dev/ttyi6 -b 9600 -g foo.\* > foo.log < /dev/null &

This command is like the previous one, except the file transfer display has
been redirected to the file foo.log.  Standard input is also redirected, to
prevent C-Kermit from sampling it for interruption commands.


    kermit -iwx

This command starts up C-Kermit as a server.  Files are transmitted with no
newline/carriage-return-linefeed conversion; the -i option is necessary for
binary file transfer and recommended for UNIX-to-UNIX transfers.  Incoming
files that have the same names as existing files are given new, unique names.


    kermit -l /dev/ttyi6 -b 9600

This command sets the communication line and speed.  Since no action is
specified, C-Kermit issues a prompt and enters an interactive dialog with you.
Any settings given on the command line remain in force during the dialog,
unless explicitly changed.


    kermit

This command starts up Kermit interactively with all default settings.

The next example shows how UNIX Kermit might be used to send an entire
directory tree from one UNIX system to another, using the tar program as
Kermit's standard input and output.  On the originating system, in this case
the remote, type (for instance):


    tar cf - /usr/fdc | kermit -is -

This causes tar to send the directory /usr/fdc (and all its files and all its
subdirectories and all their files...) to standard output instead of to a tape;
kermit receives this as standard input and sends it as a binary file.  On the
receiving system, in this case the local one, type (for instance):


    kermit -il /dev/ttyi5 -b 9600 -k | tar xf -

Kermit receives the tar archive, and sends it via standard output to its own
copy of tar, which extracts from it a replica of the original directory tree.

A final example shows how a UNIX compression utility might be used to speed up
Kermit file transfers:

    compress file | kermit -is -     (sender)
    kermit -ik | uncompress          (receiver)


1.16. UNIX Specifics


1.16.1. The UNIX File System

Consult your UNIX manual for details about the file system under your version
of UNIX.  In general, UNIX files have lowercase names, possibly containing one
or more dots or other special characters.  UNIX directories are tree-
structured.  Directory levels are separated by slash ("/") characters.  For
example,

    /usr/foo/bar

denotes the file bar in the directory /usr/foo.  Alphabetic case is significant
in UNIX file and directory names, i.e. "a" is a different file (or directory)
from "A".  Wildcard or "meta" characters allow groups of files to be specified.
"*" matches any string; "?" matches any single character.

When C-Kermit is invoked with file arguments specified on the UNIX command
line, the UNIX shell (Bourne Shell, C-Shell, K-Shell, etc) expands the meta
characters itself, and in this case a wider variety is available.  For example,

    kermit -s ~/ck[uvm]*.{upd,bwr}]

is expanded by the Berkeley C-Shell into a list of all the files in the user's
home directory (~/) that start with the characters "ck", followed by a single
character "u", "v", or "m", followed by zero or more characters, followed by a
dot, followed by one of the strings "upd" or "bwr".  Internally, the C-Kermit
program itself expands only the "*" and "?" meta characters.

UNIX files are linear (sequential) streams of 8-bit bytes.  Text files consist
of 7-bit ASCII or ISO-646 NRC characters, with the high-order bit off (0), or
in very recent versions of UNIX, of 8-bit characters in an ASCII-based
international standard character set such as ISO 8859 Latin Alphabet 1.  Text
file lines are separated by the UNIX newline character, which is linefeed (LF,
ASCII 10).  This distinguishes UNIX text files from those on most other
ASCII-based stream file systems, in which lines are separated by a carriage-
return linefeed sequence (CRLF, ASCII 13, followed by linefeed, ASCII 10).
Binary files are likely to contain data in the high bits of the file bytes, and
have no particular line or record structure.


1.16.2. UUCP Lock Files

UNIX has no built-in way of obtaining exclusive access to an external
communication line.  When you issue the 'set line' command to UNIX Kermit, UNIX
would normally grant you access to the line even if some other process is
making use of it.  The method adopted by most UNIX systems to handle this
situation is the "UUCP lock file".  UUCP, the UNIX-to-UNIX Copy program,
creates a file in its directory (usually /usr/spool/uucp, but often elsewhere)
with a name like LCK..name, where name is the device name, for instance
LCK..tty07.

UNIX Kermit uses UUCP lock files in order to avoid conflicts with UUCP, tip, or
other programs that follow this convention, including other users running
Kermit itself.  Whenever you attempt to access an external line using the 'set
line' command or `-l' on the command line, Kermit looks in the UUCP directory
for a lock file corresponding to that device.  For instance, if you 'set line
/dev/ttyi6' then Kermit looks for the file

    /usr/spool/uucp/LCK..ttyi6

If it finds this file, it gives you an error message and a directory listing of
the file so that you can see who is using it, e.g.

    -r--r--r--  1 fdc    8 Feb  7 13:02 /usr/spool/uucp/LCK..ttyi6

In this case, you would look up user fdc to find out how soon the line will
become free.

This convention requires that the uucp directory be publicly readable and
writable.  If it is not, the program will issue an appropriate warning message.

If no lock file is found, UNIX Kermit will attempt create one, thus preventing
anyone who subsequently tries to run Kermit, UUCP, cu, tip, or similar programs
on the same line from gaining access until you release the line.  If Kermit
could not create the lock file (for instance because the uucp directory is
write-protected), then you will receive an error message.

Even when the lock directory is writable and readable, the locking mechanism
depends upon all users using the same name for the same device.  If a device
has more than one path associated with it, then a lock can be circumvented by
using an alias.

When a lock-creating program abruptly terminates, e.g. because it crashes or is
killed via shell command, the lock file remains in the uucp directory,
spuriously indicating that the line is in use.  If the lock file is owned by
yourself, you may remove it.  Otherwise, you'll have to get the owner or the
system manager to remove it, or else wait for a system task to do so; uucp
supports a function (uuclean) which removes these files after a predetermined
age -- uucp sites tend to run this function periodically via crontab.

Locking is not needed, or used, if communications occur over the user's login
terminal line (normally /dev/tty).


1.16.3. C-Kermit under Berkeley or System III/V UNIX

C-Kermit may be interrupted at command level or during file transfer by typing
Control-C.  The program will perform its normal exit function, restoring the
terminal and releasing any lock.  If a protocol transaction was in progress, an
error packet will be sent to the opposite Kermit so that it can terminate
cleanly.

C-Kermit may be invoked in the background ("&" on shell commmand line).  If a
background process is "killed", the user will have to manually remove any lock
file and may need to restore the modem.  This is because the kill signal
(kill(x,9)) cannot be trapped by Kermit.

During execution of a system command ('directory', 'cd', or `!'), C-Kermit can
often be returned to command level by typing a single Control-C.  (With System
III/V, the usual interrupt function (often the DEL key) is replaced by
Control-C.)

Under Berkeley UNIX only: C-Kermit may also be interrupted by ^Z to put the
process in the background.

Control-C, Control-Z, and Control-\ lose their normal functions during terminal
connection and also during file transfer when the controlling tty line is being
used for packet i/o.

If you are running C-Kermit in "quiet mode" in the foreground, then
interrupting the program with a console interrupt like Control-C will not
restore the terminal to normal conversational operation.  This is because the
system call to enable console interrupt traps will cause the program to block
if it's running in the background, and the primary reason for quiet mode is to
allow the program to run in the background without blocking, so that you can do
other work in the foreground.

If C-Kermit is run in the background ("&" on shell commmand line), then the
interrupt signal (Control-C) (and System III/V quit signal) are ignored.  This
prevents an interrupt signal intended for a foreground job (say a compilation)
from being trapped by a background Kermit session.


1.16.4. C-Kermit on the AT&T UNIX PC

For UNIX PC owners here are a couple of hints.  The name of the phone line
devices are /dev/ph0 and /dev/ph1. The RS232 serial port is /dev/tty000.

Dialing out with the internal modem:

    C-Kermit>set line /dev/ph0
    C-Kermit>set speed 1200
    C-Kermit>set modem att7300
    C-Kermit>dial [phone]

Or use /dev/ph1 for the second phone line.  Control-C will terminate the
dialer.  The telephone line must be in the DATA state; C-Kermit will remind you
of this if it finds the line in VOICE state.

Connecting via the RS232C serial port:

    $ kermit
    C-Kermit>set line /dev/tty000
    C-Kermit>set speed 9600
        (start doing work...)
        (after exiting C-Kermit you may type:)

C-Kermit automatically handles disabling and enabling logins on the phone lines
and RS-232 port.
1.17. X.25 Support

This section applies only to UNIX C-Kermit on SUN computers that are attached
to X.25 networks via the SunLink X.25 product.

To use an X.25 connection:

    C-Kermit>set network x.25
    C-Kermit>set host aaaaaaa
    C-Kermit>connect

where aaaaaaa is the X.121 address of the host you wish to connect to.  An
X.121 address is a many-digit number consisting of a 4-digit DNIC (Data Network
Identification Code) followed by an NTN (Network Terminal Number) up to 10
digits in length, or a 3-digit DCC (Data Country Code) followed by a
country-dependent NN (National Number) up to 11 digits in length.

The following connect-mode escapes apply to X.25 terminal connections:

Ctrl-\H
    Hangup - Close the X.25 network connection.


Ctrl-\I
    Interrupt - Send an X.25 interrupt packet.


Ctrl-\R
    Reset the X.25 virtual circuit.

The following special commands can be used to control your X.25 connection:

HANGUP
    Close the X.25 network connection.


PAD CLEAR
    Clear the X.25 virtual circuit.


PAD INTERRUPT
    Send an X.25 Interrupt packet.


PAD RESET
    Reset the X.25 virtual circuit.


PAD STATUS
    X.25 status request.


SET PAD BREAK-ACTION n
    X.3 Parameter 7.  What PAD should do if it receives a BREAK signal.  0 =
    nothing, 1 = send Interrupt packet, 2 = reset, 4 = send Indication Of Break
    PAD message, 8 = escape to PAD, 16 = discard output.  Default = 21 (= 16 +
    4 + 1).


SET PAD BREAK-CHARACTER n
    Default 0.


SET PAD LINE-DELETE n
    X.3 Parameter 17.  0-127 = ASCII value of character to be used for erasing
    a line.  Default = 21 (Ctrl-U).


SET PAD CHARACTER-DELETE n
    X.3 Parameter 16.  0-127 = ASCII value of character to be used for erasing
    a character.  Default = 8 (Ctrl-H = Backspace).


SET PAD CR-PADDING n
    X.3 Parameter 9, Padding After Carriage Return (CR).  0-255.  Number of
    padding characters PAD should send to DTE after sending a CR.  Default = 0.


SET PAD DISCARD-OUTPUT { 0, 1 }
    X.3 Parameter 8.  0 = normal data delivery, 1 = discard output.  Default =
    0.


SET PAD LINE-DISPLAY n
    X.3 Parameter 18.  0-127 = ASCII value of character to redisplay an edited
    line.  Default = 18 (Ctrl-R).


SET PAD ECHO { 0, 1 }
    X.3 Parameter 2.  0 = PAD will not echo, 1 = PAD will echo.  Default = 1.


SET PAD EDITING { 0, 1 }
    X.3 Parameter 15.  0 = No editing, 1 = editing allowed.  Default = 1.


SET PAD ESCAPE { 0, 1 }
    X.3 Parameter 1.  0 = Escape to PAD not possible, 1 = Ctrl-P escapes to
    PAD.


SET PAD FORWARD n
    X.3 Parameter 3, Data Forwarding Characters.  0 = none, 1 = any
    alphanumeric, 2 = carriage return, etc.  Default = 2.


SET PAD LF-PADDING n
    X.3 Parameter 14. 0-255 padding characters to be sent by PAD after
    linefeed.  Default = 0.


SET PAD LF-INSERT n
    X.3 Parameter 13, Linefeed (LF) insertion after carriage return (CR).  0 =
    no LF insertion, 1 = PAD inserts LF after each CR sent to DTE, 2 = PAD
    inserts LF after each CR received from DTE, 4 = PAD echoes LF as CRLF.
    Default = 0.


SET PAD LINE-FOLD n
    X.3 Parameter 10, Line Folding.  0 = none, 1-255 = number of graphic
    characters per line after which to insert folding characters.  Default = 0.


SET PAD PAD-FLOW-CONTROL { 0, 1 }
    X.3 Parameter 5.  0 = No flow control by PAD, 1 = PAD may send Xon/Xoff
    flow control to user.  Default = 0.


SET PAD SERVICE-SIGNALS { 0, 1 }
    X.3 parameter 6, PAD Service and Command Signals.  0 = PAD service signals
    are not sent to DTE, 1 = PAD service signals sent.  Default = 1.


SET PAD TIMEOUT n
    X.3 Parameter 4, Data forwarding timeout, 0-255 (twentieths of a second).
    Default = 0 (no data forwarding on timeout).




SET PAD USER-FLOW-CONTROL { 0, 1 }
    X.3 Parameter 12.  0 = no flow control by user, 1 = user device may send
    Xon/Xoff flow control to PAD.  Default = 0.


SET X.25 CALL-USER-DATA { ON [ text ], OFF }
    OFF = no call user data, ON text sends the given text during call setup.


SET X.25 CLOSED-USER-GROUP { OFF, ON n }
    OFF = no closed user group, ON n specifies the user group number, 0 to 99.
    OFF by default.


SET X.25 REVERSE-CHARGE { OFF, ON }
    OFF = caller pays, ON = callee pays.  Default is OFF.


1.18. C-Kermit under VAX/VMS

This section contributed by Terry Kennedy, St. Peter's College, Jersey City,
NJ, USA.


1.18.1. File Transfer Issues

VMS provides a plethora of file formats, most of which have no direct
equivalent on other operating systems (especially the other operating systems
that C-Kermit runs under).  Thus, the user is faced with the issue of file
format conversion.  VMS C-Kermit attempts to make this as painless as possible
by mapping the various file formats to canonical form on transmission, and by
creating the simplest file structure upon reception.  Various C-Kermit commands
may be used to give C-Kermit "hints" about what the user desires.  Some of
these work only when sending files, others only when receiving files.  First,
let's discuss some terms:

BINARY TRANSFER MODE (SET FILE TYPE BINARY)

When sending a file, C-Kermit/VMS reads bytes from the file and sends them
without any kind of interpretation, translation, or reformatting.  In
particular, no characters are inserted at record boundaries.

When receiving files, C-Kermit/VMS collects bytes and writes them to disk at
intervals.  The file is created as "Fixed" organization, with the record size
specifed by the user with SET FILE RECORD-LENGTH, or the default value of 512
if the user does not override it.  For both send and receive operations, the
RMS attribute "First free byte" is used.  Thus, VMS C-Kermit can operate on
files where the file size (in bytes) is not an exact multiple of the file
record size.

TEXT TRANSFER MODE (SET FILE TYPE TEXT)

When sending files, C-Kermit/VMS attempts to convert the file to a form which
has the proper delimiters for "canonical Kermit protocol" form.  Specifically,
CR and LF characters are inserted as needed at the end of each record.  This is
normally an easy task, but is complicated by some VMS file types (such as the
"Fortran carriage control" type).  On reception, files are created as
"Sequential variable, carriage return carriage control".  C-Kermit uses a CR
followed immediately by a LF as a record delimiter.  Lone CR's or LF's are
written as part of a record if they are present.

LABELED TRANSFER MODE (SET FILE TYPE LABELED)

When in this mode, C-Kermit/VMS gathers information about the file from various
sources, such as the file's directory entry, ACL's, etc. and transmits it as
part of the file data. This is called a LABELED FILE. Such files are not usable
on non-VMS systems, but may be stored on such systems and later restored to
another (or the same) VAX. An external utility named CKVCVT reconstitutes the
file as it was, with various options.

Other systems should treat labeled files as simple files of TYPE BINARY.

Now, let's discuss the actions of sending or receiving:


1.18.1.1. Sending Files from VMS C-Kermit

The requested file is opened and the VMS file characteristics are examined.
Files of format "Undefined" or "Fixed" are sent as binary files, other formats
are sent as text files.

SET FILE TYPE IMAGE.  This forces the file to be sent as a stream of bytes,
regardless of file characteristics, with a file type of binary declared in the
attribute packet.  This is useful for cases where other applications generate
file contents with inappropriate file characteristics (for example, a stream-LF
file which is actually binary data).  This should only be used as a last
resort, as [normally] RMS inserts bytes in the file for control purposes, and
these bytes are transmitted (and misinterpreted by the receiving system).

SET FILE TYPE LABELED forces the file to be sent in labeled format, with
C-Kermit reading the file from the disk as in IMAGE mode, and with a file type
of binary declared in the attribute packet.


1.18.1.2. Receiving Files to VMS C-Kermit

The characteristics supplied in the file's attribute packet are used to
determine the desired file type.  If no attribute packet arrives, the current
SET FILE TYPE setting, TEXT or BINARY, is used.  If the current file type is
IMAGE, BINARY is used.  SET FILE TYPE UNDEFINED forces the received file to be
written with RMS RECORD FORMAT UNDEFINED for compatbility with some software
that uses non-RMS routines for manipulating files.  This option should normally
not be used, as you will generate files VMS can't do anything with.

If the current FILE TYPE is LABELED, the incoming file is handled in LABELED
mode if (a) its attribute packet declares its type to be binary, OR (b) there
is no attribute packet.  If the attribute packet says the file type is text,
C-Kermit rejects the file. At the present time, C-Kermit does not understand
received labeled files, and you should use the external CKVCVT utility to
convert them.


1.18.2. PRACTICAL APPLICATIONS


1.18.2.1. Between a VMS System and a Different System

The defaults should function properly, provided that the receiving system uses
the "stream-of-bytes" philosophy of UNIX.  Extensive testing has been done
between VMS C-Kermit and UNIX C-Kermit, as well as MS-DOS Kermit.  Other
systems may require a re-thinking of the transfer strategy, but this author
[tmk] considers it unlikely.


1.18.2.2. Between VMS Systems

The goal of the defaults is to produce useful output in the majority of cases.
If you need to transfer binary files where record boundaries are important and
don't occur at fixed intervals (such as .OBJ files), or where the file
semantics are extensive and not propagated by C-Kermit (such as DDIF files,
indexed files, or files with extended semantics stored in an ACE, such as PCSA
file service contents), you have two options.

   1. SET FILE TYPE LABELED.  Give this command to the sending C-Kermit
      system, receive the file on the target VMS system, and extract the
      contents with CKVCVT.

   2. Encapsulate these files using VMS BACKUP, transfer the BACKUP
      saveset, and then restore it on the target system.  BACKUP produces
      output files with a simple fixed length record structure.  You
      should specify an explicit record size on the BACKUP command line
      such as:

          BACKUP *.* FILES.BCK/SAVE_SET/RECORD=8192

      and give the record size to the receiving Kermit with the command
      SET FILE RECORD-LENGTH before sending your saveset.


1.18.3. Compatibility with Bliss-32 Kermit

Testing has shown that the two Kermits make similar assumptions about file
characteristics.  A variety of files were uploaded from MS-DOS to VMS with
Bliss-32 Kermit, using a variety of transfer modes, and then returned to MS-DOS
with C-Kermit and a byte-for-byte comparison was performed.  The reverse
operation was then tried and tested.  No discrepancies were found.  Although
this does not guarantee 100% compatibility, it is very close.  Equivalences:

C-Kermit/VMS                  Bliss Kermit-32

SET FILE TYPE TEXT            SET FILE TYPE ASCII
SET FILE TYPE BINARY [FIXED]  SET FILE TYPE BINARY, SET FILE TYPE FIXED
SET FILE TYPE BIN UNDEF       (none)
SET FILE TYPE IMAGE           SET FILE TYPE BLOCK
SET FILE TYPE LABELED         (none)

Note: There is no distinction between SET FILE TYPE BINARY and FIXED in
C-Kermit/VMS, and none is needed.  C-Kermit determines the file type and length
automatically when sending, and when receiving binary files, creates a
fixed-format file and marks the true end using the "first free byte" mechanism
of RMS.  EXCEPT if you have given the command SET FILE TYPE BINARY UNDEFINED,
in which case the file is stored with the RMS record format of UNDEFINED rather
than fixed (but in the same format as a fixed file).


1.18.4. Date and Time Attributes

The VMS C-Kermit server sends the file's creation date in the attribute packet
when a file is sent.  When receiving files, if there was valid date/time
information in the attribute packet, C-Kermit will set the new file's creation
date/time to the value provided.  The file will be marked as being revised once
(initial creation), on the current date/time.  This is necessary to ensure that
the file will be detected as "new" by VMS BACKUP.  You should also note that if
a file with a creation date in the future (as perceived by VMS) is received
from a remote Kermit, the system will report "File has creation date in the
future" to your system management if they use the ANALYZE/DISK command before
the file's creation date has occured.

VMS C-Kermit has the command SET FILE COLLISION UPDATE, which can be used to
reject files when there is a newer file than the incoming one with the same
name.  If you use this option, be aware that due to system clock skew, you may
be able to send the file several times in succession before VMS C-kermit
rejects it as [now] being older than the one on the VAX.


1.18.5. File Size Attributes

When sending files, VMS C-Kermit fills in the file size information in the
attribute packet. Note that the reported sizes may differ from the actual size
due to insertion of CR/LF characters on transmission.

For received files, VMS C-Kermit checks checks for sufficient free disk space
if the remote Kermit supplies file size information. If there isn't enough
space on the disk, VMS C-Kermit will reject the file. Please note that user
quotas are not checked. The logic to do so is quite complicated, and would lead
to VMS C-Kermit rejecting files that could be received. As an example, consider
a user with EXQUOTA privilege. In general, a file size rejection by VMS
C-Kermit means the file will not fit; the lack of a rejection does not
guarantee that the file will fit. Consider a small file being received onto an
RX50 floppy. If debugging is turned on, the debug output will fill the floppy
before the file is completely received.

If the device for the received file is not a disk (for example, the system
lineprinter) the file is assumed to always fit.


1.18.6. SET FILE TYPE LABELED

Labeled files contain various pieces of information needed to reconstruct the
file. At the moment, this is handled by an external utility known as CKVCVT.
Some items are always restored and other are not restored unless the user
explicitly asks for them. File characteristics are always restored.  The file
name is restored (de-truncated). However, the complete directory specification
is not used to recreate the file unless explicitly requested.  This means that
converted files will normally be restored to your current directory. Similarly,
file ownership is assigned to you unless you specify that the original owner be
retained. Note that the two previous options will require privileges. The file
backup date is normally cleared so that the file will be backed up. This action
may be overridden.

File ACE's are normally not restored. This is an all-or-nothing operation, as
there are many types of ACE's under VMS. The most common usage of an ACE is to
grant/deny file access to other users. However, various other uses exist. Some
examples are: RMS Journaling, RMS Statistics, DDIF, and Pathworks.  Note that
ACE's are transported in binary mode, which means that protection ACE's may
wind up applying to incorrect users if you move files between different VMS
systems with ACE's enabled. Also, note that you can create ACE's which you
cannot see with DIR/FULL unless you have SECURITY privilege.  However, you
should be able to view (but not modify) them with EDIT/ACL. This also means
that you will not be able to delete these ACE's without deleting the file,
which is another reason they are normally not restored.

RMS Journaling files are a special case. Journaling will not be enabled for a
received labeled file. A DIR/FULL will show the journaling ACE, which you can
use to determine the correct journaling paramters if you wish to journal the
new file. Note that if you restore the file to another disk (even if it is on
the same system) the journaling information will display incorrectly.  This is
a limit of the DEC RMS Journaling product.


1.18.7. Reporting Problems

If you have a file that does not transfer correctly, or that exhibits a problem
when moved one way with Bliss-32 Kermit and the back with C-Kermit, we would be
interested in seeing it (especially if it's small 8-).  Please make a BACKUP
saveset of it under VMS, and send the saveset along to the BUGS address (use
the command BUG in C-Kermit for up-to-date information).  Please include any
specific information you think would be useful.  As a bare minimum, please give
the Kermit version number(s), the VMS version, and the compiler version (if you
re-compiled Kermit).
1.18.8. Sections that need to be added

Hints for users and system managers on configuring their VMS system and
terminal devices for best use with Kermit -- BYTLM quotas, Alt-typahead
buffers, etc etc.  What are the sysgen options, what SET TERMINAL commands (if
any) should be used before running C-Kermit, etc...


1.19. C-Kermit under OS/2

This section describes special considerations for using C-Kermit under OS/2.

C-Kermit 4E(72) was adapted to OS/2 by Chris Adie of Edinburgh University,
Scotland, UK.  The OS/2-specific code was adapted to version 5A(179) and parts
of it were rewritten by Kai Uwe Rommel of the Technical University of Munich,
Germany.

C-Kermit is a protected-mode program.  It will not run in the DOS compatability
environment.  This means that it will continue running (eg transferring files)
even when it is not the foreground session.

The OS/2 C-Kermit initialization file is called CKERMIT.INI.

All numbers in the C-Kermit documentation are decimal unless noted otherwise.


1.19.1. Requirements

C-Kermit will run on a computer with an 80286 or 80386 processor running OS/2
version 1.0 or higher.  It runs in character mode - in other words it is not a
Presentation Manager application.  However, it will run in a Presentation
Manager window as a character application.  Normally, though, you would run it
from the command processor (CMD.EXE) prompt.


1.19.2. The Serial Port

Naturally, a serial port (COM1 through COM4) is required. The OS/2 serial port
device driver must be loaded using a line like one of the following in the
CONFIG.SYS file:

                        DEVICE=COM01.SYS
    or                  DEVICE=COM02.SYS
    or                  DEVICE=COM.SYS

COM01.SYS is used for PC/AT - type machines, while for PS/2s COM02.SYS must be
used. C-Kermit will not work if this device driver is not loaded. (It provides
the Category 1 IOCTLs which are used extensively within the program.) COM01.SYS
and COM02.SYS are used for version 1.x of OS/2 only. For the version 2.0 of
OS/2 (soon to be released), only one driver COM.SYS exists for both types of
machines.

The connecting cable and the modem (or other computer, PAD etc to which your
computer is connected) must satisfy the requirements of your computer's RS232
interface.  In particular, the computer will provide two output control signals
(RTS and DTR), and may expect to see signals on four input lines (DCD, DSR,
CTS, RI).  The precise behaviour of these lines is software configurable (for
instance by using the OS/2 'MODE' command), and C-Kermit makes no attempt to
impose a particular method of using them.

By default, the DTR and RTS line will both go ON when C-Kermit opens the comms
port, and they will go OFF when it is closed.

The default behaviour for the input lines is that DSR and CTS must be ON to
enable the port to work.  If the modem you are connected to does not provide
these signals, you can 'loop back' the RTS output signal from the computer to
DSR and CTS, using a suitably modified cable.  An alternative is to use the
MODE command to disable the DSR and CTS inputs.  To do this, type a command
similar to the following at the OS/2 CMD prompt:

    MODE COM1:9600,N,8,1,OCTS=OFF,ODSR=OFF,IDSR=OFF

You can check the effect using:

    MODE COM1

which reports the current settings of COM1.  Note that on some machines,
C-Kermit may appear to work even although DSR and CTS are not connected to
anything, nor disabled using 'MODE'.  This is because unconnected input lines
tend to 'float high'.  Although this situation may not cause any problems, it
is not good practice - you should explicitly disable the inputs as above.

The 'MODE' utility also allows you to change the baud rate, parity, number of
data bits and number of stop bits.  C-Kermit provides facilities for changing
the baud rate and parity too (see later in this manual), but when it starts up,
it resets the parity to none and the number of data bits to 8.  Any changes to
baud rate and parity will remain in effect after C-Kermit terminates.

If you change the parity within C-Kermit, it will ajust the number of data bits
to cope.  There is no way of changing the number of stop bits within C-Kermit:
use 'MODE' to do this.

There is also no way to change the hardware flow control settings from within
C-Kermit. There are too many possible settings for the OS/2 serial driver to
duplicate all 'MODE' options into C-Kermit. You can use 'MODE' to adjust the
hardware flow control and the settings are used by C-Kermit without
modification. You can, however, change the software flow control from within
C-Kermit.


1.19.3. Emergency Exit

EMERGENCY EXIT:  The Control-C and Control-Break keys cannot be used to
terminate C-Kermit.  To terminate C-Kermit unconditionally, you can select it
in the task list and choose 'Terminate' (OS/2 1.x) or select it in the window
list and choose the 'Close' option from the menu (OS/2 2.0).

C-Kermit returns an exit status of zero, except when a fatal error is
encountered, when the exit status is set to one.  This can be used in a batch
file, to take some action depending on whether the operation was successful.
For instance, suppose the file SEND.CMD contains the following:

    echo Sending %1 out port %2
    kermit -ql COM%2 -b 9600 -s %1
    if ERRORLEVEL 1 goto badend
    echo Transferred succcessfully!
    goto end
    :badend
    echo Transfer problems!
    :end

To send a file FOO.BAS, you could type:


    send foo.bas 2

to send it to another computer running Kermit, connected to port COM2.  If the
transfer completed OK, you would get the message 'Transferred successfully!'.


1.19.4. The OS/2 File System

The features of the OS/2 file system of greatest interest to Kermit users are
the form of the file specifications, and the formats of the files themselves.
Note that the following discussion refers to the MS-DOS compatible file system
supported by initial versions of OS/2.  Installable file systems are not
covered here - they are significantly different, and the extent to which
C-Kermit will work under such file systems is unknown (because no installable
file system has been released at the time of writing).


1.19.4.1. File Specifications

OS/2 file specifications are of the form


    DEVICE:\PATHNAME\NAME.TYPE

where DEVICE stands for a single character identifier (for instance, A for the
first floppy disk, C for the first fixed disk, D for a RAM disk emulator)
followed by a colon (':'), PATHNAME is up to 63 characters of identifier(s) (up
to 8 characters each) surrounded by backslashes ('\'), NAME is an identifier of
up to 8 characters, and TYPE is an identifier of up to 3 characters in length.
Device and pathname may be omitted.  The first backslash in the pathname may be
omitted if the specified path is relative to the current directory.  In the
path field, '.' means the current directory, '..' means the parent directory.

Note that the name, type and path length restrictions apply to the original FAT
file system of OS/2. The HPFS file system added in later revisions does not
have such hard restrictions. However, C-Kermit will not take much advantage of
the long HPFS file names except that it recognizes them when sending/receiving
files.

The device and directory specification is normally omitted, but can be
specified in all C-Kermit commands.  Device and directory pathnames, when
omitted, default to either the user's current disk and directory, or to the
current directory search path as specified in the PATH environment variable,
depending on the context in which the file name appears.

The C-Kermit command line parser treats backslash characters specially and thus
requires you either to enter two backslashs when you want to enter one in a
file specification or to enter a forward slash instead.  The following two
commands are equivalent.

    C-Kermit>send c:\\autoexec.bat
    C-Kermit>send c:/autoexec.bat

NAME.TYPE is sufficient to specify a file on the current disk and directory,
and only this information is sent along by C-Kermit with an outgoing file (by
default).

The device, path, name, and type fields may contain uppercase letters, digits,
and the special characters '-' (dash), '_' (underscore), '$' (dollar sign), '&'
(ampersand), '#' (number sign), '@' (at sign), '!' (exclamation mark), '''
(single quote), '()' (parentheses), '{}' (curly braces), '^' (caret or
circumflex), '~' (tilde), and '`' (accent grave).  Normally, you should confine
your filenames to letters and digits for maximum transportability to non-OS/2
systems (by default, C-Kermit will translate filenames being sent by converting
non-alphanumeric characters to 'X').  When you type lowercase letters in
filenames, they are converted automatically to uppercase.  There are no
imbedded or trailing spaces.  Other characters may not be included; there is no
mechanism for "quoting" otherwise illegal characters in filenames.  The fields
of the file specification are set off from one another by the punctuation
indicated above (ie colon, backslash and dot).

The name field is the primary identifier for the file.  The type, also called
the extension or suffix, is an indicator which, by convention, tells what kind
of file we have.  For instance FOO.BAS is the source of a BASIC program named
FOO; FOO.OBJ might be the relocatable object module produced by compiling
FOO.BAS; FOO.EXE could be an executable program produced by loading FOO.OBJ,
and so forth.  .EXE is the normal suffix for executable programs.

OS/2 allows a group of files to be specified in a single file specification by
including the special "wildcard" characters, '*' and '?'.  A '*' matches any
string of characters from the current position to the end of the field,
including no characters at all; a '?' matches any single character.  Here are
some examples:

*.BAS           All files of type BAS (BASIC source files) in the current
                directory.

FOO.*           Files of all types with name FOO.

F*.*            All files whose names start with F.

*.?             All files with types exactly one character long, or with no
                type at all.

Wildcard notation is used on many computer systems in similar ways, and it is
the mechanism most commonly used to instruct Kermit to send a group of files.

You should bear in mind that other (non-OS/2) systems may use different
wildcard characters.  For instance VMS and the DEC-20 use '%' instead of '?' as
the single character wildcard; when using C-Kermit to request a wildcard file
group from a Kermit-20 server, the OS/2 '?' must be replaced by the DEC-20 '%'.


1.19.4.2. File Formats

OS/2 systems store files as streams of 8-bit bytes, with no particular
distinction among text, program code, and binary files.  ASCII text files
consist of lines separated by carriage-return-linefeed sequences (CRLFs), and
this conforms exactly to the way Kermit represents text files during
transmission.

OS/2 (unlike CP/M) knows the exact end of a file because it keeps a byte count
in the directory, so one would expect no particular confusion in this regard.
However, certain MS-DOS and OS/2 programs continue to use the CP/M convention
of terminating a text file with a Control-Z character. This may cause problems
when the file is transferred elsewhere, since other systems may object to the
Control-Z. By default, therefore, C-Kermit treats the first Control-Z it finds
in the file as being equivalent to end-of-file. The Control-Z is not
transmitted to the other system. Of course, this leads to problems when
transferring non-text files, when we do want any Control-Zs in the file to be
sent. To achieve this, the C-Kermit 'set file type binary' command may be used.
The opposite, 'set file type text', is the default.


1.19.5. Terminal Emulation

The CONNECT-mode escape character is Ctrl-] (Ctrl-Rightbracket) by default, but
you can change it to any other control character with the SET ESCAPE command.

In connect mode, C-Kermit emulates a DEC VT102 terminal.  See the section
"Terminal Emulation" for details of how the emulation works.

In CONNECT mode, keyboard input is obtained through the KBD subsystem, and
screen output is through the VIO subsystem. It is therefore impossible to
redirect terminal I/O.

When you issue a 'connect' command the first time after starting Kermit, the
screen clears and the cursor is positioned at the top left-hand corner.  You
can log into the remote host computer as normal.  In this mode, the PC emulates
a DEC VT102 terminal, so any control codes or escape sequences received from
the host will be actioned appropriately.

The 25th line on the screen is used as a status line, giving the name of the
communications port, the current transmission speed, and how to obtain help.

Some keys on the VT102 keyboard have no direct equivalent on the PC keyboard.
The following table shows the mapping which obtains between VT102 keys and PC
keys.  Note that the Alt n combinations use the number keys along the top row
of the keyboard, not the numeric keypad.
 VT102              IBMPC

Delete              Del
PF1                 F1
PF2                 F2
PF3                 F3
PF4                 F4
Keypad 0            Alt 0
Keypad 1            Alt 1
Keypad 2            Alt 2
Keypad 3            Alt 3
Keypad 4            Alt 4
Keypad 5            Alt 5
Keypad 6            Alt 6
Keypad 7            Alt 7
Keypad 8            Alt 8
Keypad 9            Alt 9
Keypad minus        F5 or F6
Keypad comma        F7 or F8
Keypad dot          F9
Keypad enter        F10
No Scroll           Scroll-Lock

The PC's 'Scroll-Lock' key (equivalent to the VT102 'No Scroll' key) freezes
the data on the screen. It is typically used when listing a long file, to
prevent information being scrolled off the top of the screen. Note that the
Control-S and Control-Q (Xon/Xoff) keys should not be used for this purpose if
'flow' is set to 'xon/xoff', because they interfere with the correct operation
of the comms device driver flow control. When the 'Scroll-Lock' key is pressed,
an 'xoff' will be sent automatically when the device driver's receive buffer
fills up, and an 'xon' will be sent as it empties after the 'Scroll-Lock' key
has been pressed a second time to unfreeze the screen. All other keys are
ignored when the screen is frozen. The status line indicates when the emulator
is in this state.

Information which scrolls off the top of the screen is not in fact lost, but is
stored in an "extended display buffer", which can be examined by pressing the
'PgUp' key. The extended display buffer can contain a number of screenfulls of
data, and the 'PgUp' and 'PgDn' keys can be used to range freely through this
data. If any other key is pressed while the extended display buffer is visible,
the current screen contents are redisplayed and the keystroke is sent to the
host. The 'PgUp' and 'PgDn' keys may be used even when the host is still
sending data. If Xon/Xoff flow control is in effect, no data will be lost.

The following VT102 features are not implemented:

   - Smooth scrolling

   - 132-column mode

   - Alternate character ROM

   - LED lamps

The VT102 keyboard autorepeat mode is always enabled.

When in connect mode, typing the escape character (Control-]) followed by a ?
for help will display a "pop-up" help window, indicating the options available.
If ^]c is typed to close the connection, the screen is restored to its state
when the 'connect' command was issued.  A subsequent 'connect' will re-display
the VT102 screen.

The control codes and escape sequences recognised by the VT102 emulation are
listed below.  For full details of the effects of these codes, please consult
the VT102 manual.

ENQ           5     Send answerback message "OS/2 Kermit"
BEL           7     Sound beep
BS            8     Cursor left
TAB           9     Cursor to next tab stop
LF            10    Cursor down
VT            11    As LF
FF            12    As LF
CR            13    Cursor to left margin
SO            14    Select G1 character set
SI            15    Select G0 character set
CAN           24    Cancel escape sequence
SUB           26    As CAN
ESC           26    See below
Others              Ignored

ESC 7         Save cursor position
ESC 8         Restore cursor position
ESC D         Index
ESC E         Next line
ESC H         Set tab at current column
ESC M         Reverse index
ESC Z         Identify terminal
ESC c         Reset
ESC =         Enter application keypad mode
ESC >         Exit application keypad mode
ESC # 3       Double height and width emulation, top half line
ESC # 4       Double height and width emulation, bottom half line
ESC # 5       Single height and width
ESC # 6       Single height and double width emulation
ESC # 8       Screen alignment display
ESC ( g             G0 designator - g = A,B or 0 only
ESC ) g             G1 designator - g = A,B or 0 only
ESC [ Pn A          Cursor up
ESC [ Pn B          Cursor down
ESC [ Pn C          Cursor right
ESC [ Pn D          Cursor left
ESC [ Pl ;Pc H      Direct cursor address
ESC [ Pl ;Pc f      Direct cursor address
ESC [ Pn c          Identify report - response is ESC [ ? 6 ; 2 c
ESC [ 3 g           Clear all tabs
ESC [ 0 g           Clear tabs at current column
ESC [ ? Pn h        Set DEC private mode, shown below
ESC [ ? Pn l        Reset DEC private mode, shown below

    mode no.        mode            set           reset

        1           Cursor key      Application   Cursor
        2           ANSI/VT52       N/A           VT52
        5           Screen          Reverse       Normal
        6           Origin          Relative      Absolute
        7           Wraparound      On            Off

ESC [ Pn h          Set mode - modes supported as shown below
ESC [ Pn l          Reset mode - modes supported as shown below

    mode no.        mode            set           reset

        2           Keyboard lock   On            Off
        4           Insert          Insert        Replace
       20           Newline         CR LF         CR
ESC Pn i            Printer/screen on/off - 4 to 7 supported
ESC [ 5 n           Status report
ESC [ 6 n           Cursor position report
ESC [ Pn x          Request terminal parameter
ESC [ Pn ;Pn r      Set top and bottom margins
ESC [ 0 J           Erase to end of screen
ESC [ 1 J           Erase from beginning of screen
ESC [ 2 J           Erase all of screen
ESC [ 0 K           Erase to end of line
ESC [ 1 K           Erase from beginning of line
ESC [ 2 K           Erase all of line
ESC [ Pn L          Insert blank lines
ESC [ Pn M          Delete lines
ESC [ Pn @          Insert blank characters
ESC [ Pn P          Delete characters
ESC [ Ps ;Ps ; ..;Ps m    Character attributes or
ESC [ Ps ;Ps ; ..;Ps }    Character attributes, as below:
0       Default settings
1       High intensity
4       Underline
5       Blink
7       Reverse
8       Invisible
30-37   sets foreground colour to be as shown
        30      black
        31      red
        32      green
        33      yellow
        34      blue
        35      magenta
        36      cyan
        37      white
40-47   sets background colour to be as shown
        40      black
        41      red
        42      green
        43      yellow
        44      blue
        45      magenta
        46      cyan
        47      white

Note that the default character set for both G0 and G1 is 'A', ie the UK
character set.

The following escape sequences are recognised when the emulator is put into
VT52 mode by receiving the sequence ESC [ ? 2 l.

ESC A         Cursor up
ESC B         Cursor down
ESC C         Cursor right
ESC D         Cursor leftup
ESC F         Enter graphics mode
ESC G         Exit graphics mode
ESC H         Cursor to home
ESC I         Reverse line feed
ESC J         Erase to end of screen
ESC K         Erase to end of line
ESC Y l c     Direct cursor address
ESC Z         Identify
ESC =         Enter application keypad mode
ESC >         Exit application keypad mode
ESC <         Enter ANSI mode

The escape sequences below are accepted but ignored.

    ESC O x       where x is any character
    ESC ? x       where x is any character
    ESC [ Pn q    Load LEDs


1.19.6. Keyboard mapping

The OS/2 version of C-Kermit provides the same keyboard mapping as the UNIX
version. A particular key can be mapped to itself (default for all keys), to
another key (single key stroke) or to a sequence of key strokes (a macro text).
Use the SET KEY command for this purpose.

An extension was made to the standard SET KEY command to allow mapping of the
additional PC keyboard keys. Unlike the UNIX version, the OS/2 version knows of
768 rather than only 256 keys. The keys 0..255 are the usual ASCII and extended
ASCII (8-bit PC-specific) characters while all extended keys (such as cursor
and function keys) in various combinations with SHIFT, CONTROL and ALT are
known as 256..767 to C-Kermit. To find out what the number of some key is,
enter the SHOW KEY command and press that key. The SHOW KEY command will then
report the key number and the current assignment.

Note that a few extended keys have a special meaning to the VT-102 emulator in
CONNECT mode. The cursor keys, for example, send the VT-102 cursor key escape
sequences while Page-Up and Page-Down are used to control the emulator's
scrollback buffer.

That means, the CONNECT mode knows a few key numbers and treats them specially.
If you map another key to the code of one of this special known keys, that
other key will also function like this special key.


1.19.7. OS/2 C-Kermit Restrictions and Known Bugs

   1. Server breakout:  There is no way of stopping server operation from
      the keyboard, short of Control-C.

   2. Debugging log:  There is very little debugging information logged
      from the OS/2-specific parts of the program (it was developed using
      Codeview).

   3. Terminal emulation:  If the host sends the escape sequence to put
      the terminal into 132-column mode, and subsequently sends data which
      would appear in the rightmost 52 columns, this may mess up the
      existing data on the screen.  Really the emulator should ignore any
      data for these columns.

   4. File type:  The way Control-Z is handled could be better.  We need a
      'set ctrlz {on, off}' like MS-DOS Kermit.

   5. A better display of progress of a transfer is needed.


1.19.8. Invoking OS/2 C-Kermit from Another Program

If you are writing a communications program and wish to incorporate the Kermit
protocol within it, one way is to use the OS/2 function call DosExecPgm to call
up C-Kermit.  You would supply the instructions for Kermit using command-line
options, and Kermit would do the transfer, returning back to your program when
it had finished.

The only problem with this scenario is that you might already have opened up
the COM port within your program, so that when Kermit tries to do the same it
gets an error code back from DosOpen.  The -u command line option gets round
this problem.  It uses the fact that a child process inherits the open file
handles of its parent.  -u takes one numeric parameter which is the handle of
the COM port in question, and it must occur in front of any other command-line
parameter which accesses the COM port.  The following is a complete C program
written using the Microsoft C compiler version 5.1 and the Microsoft OS/2
Software Development Toolkit, which illustrates how to use the -u command-line
option (NOTE: the UNIX version uses -l for this).
#define INCL_BASE
#include <os2.h>
/*
 *      Example of how to use the C-Kermit -u option to invoke
 *      Kermit from another program under OS/2.
 */
main(int argc, char *argv[]) {
HFILE   ttyfd;
USHORT  action;
int     err,i;
char    failname[80];
char    args[80];
RESULTCODES     res;
struct dcb {                    /* Device control block */
        USHORT write_timeout;
        USHORT read_timeout;
        BYTE flags1, flags2, flags3;
        BYTE error_replacement;
        BYTE break_replacement;
        BYTE xon_char;
        BYTE xoff_char;
} ttydcb;

        /*** Open a file ***/
        if (err=DosOpen(argv[1],&ttyfd,&action,0L,0,1,0x0012,0L)) {
                printf("Error %d opening %s\n",err,argv[1]);
                exit(1);
        }
        if (err=DosDevIOCtl(&ttydcb,NULL,0x0073,1,ttyfd)) {
                printf("Error %d from IOCTL on %s\n",err,argv[1]);
                exit(1);
        }
        ttydcb.flags3 &= 0xF9;
        ttydcb.flags3 |= 0x04;  /* Read "some" data from line */
        DosDevIOCtl(NULL,&ttydcb,0x0053,1,ttyfd);

        /*** Call kermit ***/
        strcpy(args,"ckoker");
        i = strlen(args);
        args[i++]=0;
        sprintf(&args[i],"-u %d -q -s test.c",ttyfd);
        i += strlen(&args[i]);
        args[i++]=0;
        args[i++]=0;
        if (err=DosExecPgm(failname,80,EXEC_SYNC,args,NULL,&res,
                                                    "KERMIT.EXE")) {
                printf("Error %d executing Kermit\n",err);
                exit(1);
        }

        /*** Print out return code ***/
        printf("Termination code %d\n",res.codeTerminate);
        printf("Result code %d\n",res.codeResult);

        /*** Close the file ***/
        if (err=DosClose(ttyfd)) {
                printf("Error %d closing %s\n",err,argv[1]);
        }
}
1.20. C-Kermit on the Commodore Amiga

This section written mostly by Jack Rouse and Stephen Walton.

This version of Amiga Kermit is a port of the UNIX C-Kermit which attempts to
reproduce as much of the functionality of UNIX version as possible.  I had two
main goals in porting C-Kermit:  I wanted a reliable remote file transfer
utility, and I wanted to investigate the use of the AmigaDOS and Exec
environments.

Amiga Kermit currently provides a line oriented user interface.  The DIAL and
SCRIPT commands are as yet unimplemented.  Therefore, only Amiga specific
features are noted below.


1.20.1. Invoking C-Kermit

Amiga Kermit is usually invoked from a CLI process.  However, you can also
start it from a Tool type icon, at least for the version of Kermit compiled
with Manx Aztec C. Create a Tool icon, called Kermit.info, and make sure that
it contains a ToolType entry for WINDOW= followed by some window specification.
This is actually a small dummy window, as C Kermit will open and use its own
window.

From a CLI window, you generally enter:

    KERMIT

or

    RUN KERMIT

to execute Kermit and start up the Kermit command interpreter.  Make sure you
set your stack to at least 10000 with the AmigaDOS Stack command first.  Kermit
will create its own window and greet you with:

       C-Kermit S/W, 5A(180) BETA 8 Feb 92, Commodore Amiga
       Type ? or 'help' for help
       C-Kermit>

The cursor will appear following the C-Kermit> prompt.  Typing ? will produce a
list of the items that can be entered at any point.

Typing ? at various points during command entry will help you navigate through
the command processor.  The 'help' command is also quite useful.

The Kermit command processor is normally exited with the 'QUIT' command.
During Kermit protocol, you can type CTRL-C or CTRL-D to interrupt and exit
Kermit.  Depending on the version of the C runtime libraries used to link
Kermit, the interrupt may also be active during command input, but it is
disabled during connect mode.  You will get a requestor when the interrupt is
activated to allow you to choose to continue Kermit.  However, any serial read
or write that was interrupted will still be aborted.

Kermit can also be used without the command processor by specifying an action
on the command line.  You can enter 'kermit -h' at the CLI prompt to get a list
of command line options.  However, unless input is redirected, or the -q
(quiet) option is specified, Kermit will still create a window for protocol
monitoring and interruption.  'KERMIT <*' can be used to run Kermit completely
within the CLI window; however, this does not allow you to enter control
characters, and no console input is seen until you enter return.  Input and
output can be redirected to files to take advantage of C-Kermit command line
file transfer options.  Unfortunately, AmigaDOS does not implement pipes (yet).


1.20.2. Kermit Serial Initialization and Settings

Amiga Kermit uses the serial device or a reasonable emulation thereof.  Three
sources are used to initialize the serial parameters.  First, the default
serial configuration, as set by Preferences, is copied.  This includes baud
rate, and under version 1.2 of the Workbench, parity, modem control (7-wire vs.
3-wire), and flow control.  Second, command line parameters can be used to
override these settings.  For example:

    kermit -b 1200 -p e

can be used to select 1200 baud and even parity independently of the
Preferences settings.  Finally, if the command processor is used, Kermit looks
for a .kermrc initialization file, first in the s: directory, then in the
current directory, providing that the disk containing each directory is present
in the Amiga.  The .kermrc file contains C-Kermit commands which can be used to
initialize the C-Kermit environment as desired.

The Kermit SET LINE command has a special form in Amiga Kermit, namely:

    SET LINE device/unit

where device is the name of a device (including the .device extension) and unit
is the unit number.  The default setting is equivalent to:

    SET LINE serial.device/0

The modem control mode is currently selected by 'SET MODEM type', which has two
choices: 'DIRECT', for 3-wire control, and 'GENERIC', for 7-wire control.
Because of the way the serial device operates, this setting only has an effect
when the serial device is opened after previously being closed, which occurs
only when the serial line is used after Kermit starts or after '<escape>H' is
used to hang up and exit connect mode.

Kermit allows you to set any baud rate between 110 and 292000 baud; however, it
will complain if the baud rate is nonstandard.  Rates of 110 and 111 baud are
implemented as 112 baud.  Rates above 38400 baud can be used for connect mode,
but they are not very useful for file transfer.  The file transfer rate is
limited by packet retries due to transfer errors, and the overhead time spent
constructing packets.

Amiga Kermit uses the serial device in shared mode.  This allows other
programs, like dialers, to use the serial line at the same time, without
exiting Kermit.  This could also allow in theory a terminal emulator to be used
simultaneously with Kermit.  However, if two programs are reading from the
serial line at the same time, the results are unpredictable.  Any such program,
therefore, would have to be disabled from reading while Kermit is performing
file transfer or is in connect mode.  Note that Kermit since does its own
parity generation and stripping, so it always sets the serial device to use
eight bit characters with no parity.


1.20.3. Amiga Wildcards

Both the SEND command invoked from the Amiga and a GET sent to an Amiga in
server mode use allow wildcarding, in the UNIX style.  Thus, '*' wildcard
matches an arbitrary string while '?' matches an arbitrary character.
Therefore, to get all the C source files which begin with 'cki' from the Amiga
server, you could use the command:

       C-Kermit>get cki*.c

Multiple '*' wildcards can be used in a pattern.  Remember, the wildcarding
that is used in local and remote server commands that invoke AmigaDOS commands
is the AmigaDOS form.


1.20.4. Local and Remote Commands

Amiga Kermit provides several ways to invoke AmigaDOS commands from within
Kermit.  Entering '!' at the Kermit prompt will create a CLI process running in
its own window, and wait for it to terminate.  The form '! command' will invoke
the given command command with its output going to Kermit's window.  There is
currently no way to pause the output of commands invoked his way, other than
the stopgap use of the right mouse button.  The form 'REMOTE HOST command' can
be sent to the Amiga server to execute the given command remotely on the Amiga.
Because of the way AmigaDOS Execute() function works, commands invoked in
either the '! command' or 'REMOTE HOST command' forms have NIL: as their
standard input.  Some AmigaDOS commands that require input, such as DiskCopy
and Format, do not recognize the immediate end of file that they receive under
this condition, causing them to hang.

In addition to the methods given above, various AmigaDOS commands are invoked
by local Kermit commands, and generic remote commands.  These are listed below:

AmigaDOS command    Local command      Remote generic command
DELETE files        --none--           REMOTE DELETE files
TYPE files          --none--           REMOTE TYPE files
INFO                SPACE              REMOTE SPACE
LIST obj            DIRECTORY obj      REMOTE DIRECTORY
STATUS              --none--           REMOTE WHO

Any parameters to these commands are expected to use AmigaDOS conventions,
including AmigaDOS wildcarding.  Note that in order to pass a '?' through the
C-Kermit command processor, it must be prefixed with a '\'.

You can change the current directory of the Kermit process locally with the CWD
command and remotely with REMOTE CWD.  The local CWD command prints out the
name of the current directory afterwards.  If no new directory is given, the
current directory is not changed, so CWD alone can be used to determine where
the current directory is.


1.20.5. Server Mode

Amiga Kermit completely implements server mode, including the ability to
execute CLI commands remotely.  Currently CLI commands are executed with their
standard output directed to RAM:PIPE-HOLDER, which is then written back to the
commanding Kermit after the command completes.

There are a few limitations on the commands that can be executed remotely.
First of all, if they produce voluminous output, the output should be
redirected (redirection is supported on the REMOTE HOST command line) to avoid
using all free memory for the output file.  However, the commanding Kermit will
probably timeout in the middle of the execution of any such command.  The best
way to use these commands is to

       REMOTE HOST RUN command >outfile parameters

then use REMOTE WHO (which invokes STATUS) to monitor the command for
completion.

The input stream for remote commands is NIL:, which is not handled
intelligently by all Amiga commands.  For example, 'REMOTE HOST diskcopy df0:
to df1:' hangs indefinitely while waiting for NIL: to press return.  Finally,
since each command is executed in a separate CLI, commands that set unshared
process parameters, like 'cd', will have null effect (but 'REMOTE CWD dir' can
be used instead).

While server mode is active, AmigaDOS requestors are disabled.  This avoids
requiring operator intervention to reset a requestore when the Amiga server is
told to use a file on a disk that does not exist or is write protected.
However, disabled requestors are currently not inherited by the CLI processes
that the server creates to execute remote commands.  Therefore, a remote
AmigaDOS command can still cause the server to become hung.

To shut down the Amiga server, enter BYE or FINISH at the commanding Kermit.
FINISH exits to whatever level the server was invoked from, while BYE exits
Amiga Kermit altogether.


1.20.6. Connect Mode

Connect mode on Amiga Kermit currently provides you with a standard AmigaDOS
console device window.  Using the default Preferences setting, this gives a 23
row by 77 column screen.  However, the MoreRows program allows you to increase
the size of the Workbench window beyond the 640 by 200 default size; increasing
the number of rows by 8 and the number of columns by 16 will allow a 24 row by
80 column Kermit window.  The Amiga console device is used to provide ANSI
terminal emulation.  While you are in connect mode, you can give single
character commands which are prefixed by an escape character which can be set
from within C-Kermit.  By default, the escape character is CTRL-\.  You can use
'<escape>H' to close the serial device and exit connect mode, which makes the
DTR line drop causing most modems to hang up the phone line.

You can currently get a 25 by 80 screen in Kermit by means of a kludge.
Entering the Kermit command line (backslashes will be echoed only once):

    ECHO \\033[25t\\033[80u\\033[0x\\033[0y\\014

activates console device private escape sequences that cause the console to use
a 25 by 80 region, overwriting the borders of the Kermit window.  Using window
gadgets will cause the borders to be redisplayed, but the display can be
cleaned up by typing ctrl-L in command mode.  To reset the window to its normal
condition, allowing resizing, use:

    ECHO \\033[t\\033[u\\033[x\\033[y\\014

and then activate a window gadget to refresh the borders.  These commands can
be placed into Kermit TAKE files.

In addition to the standard connect mode commands, extra logging control has
been added.  If a session log file is open, the '<escape>Q' sequence allows you
to temporarily suspend logging.  The '<escape>R' sequence resumes logging if it
has been suspended.

Features have also been added to prevent deadlocks while in connect mode due to
spurious XOFF's or bad modem control line states.  When connect mode is unable
to send serial output, keyboard characters are queued until they can be
transmitted.  Queuing continues as long as space is available in the output
buffer.  If the buffer, which is 64 characters long, fills up, the next
keyboard input is discarded and the display 'beeps'.  To get out of a deadlock
situation, you can either exit connect mode, or send a break.  In either case,
the output queue is flushed, and current serial output character is given one
second to finish transmitting.  If it does not complete, the output is aborted,
and XOFF mode reset as appropriate.  Then connect mode is exited or a break is
sent, as specified.  When output characters are queued, connect status
(accessed by '<escape>S') will indicate the number of queued output characters.


1.21. C-Kermit under OS-9

C-Kermit was adapted to OS-9 by Christian Hemsing, RWTH, Aachen, Germany, and
Bob Larson of the University of Southern California.  This section of the
manual was written by Christian Hemsing.

The commands and operation of OS-9 C-Kermit should be identical to those of
UNIX C-Kermit, with the exceptions noted here and in the "beware file".

The initialization file is .kermrc.


1.21.1. OS-9/68K Background

OS-9/68k is a multiuser, multitasking operating system designed to run on all
Motorola 680x0 family processors from Microware Systems Corporation, 1900 N.W.
114th Street, Des Moines, Iowa 50332 (Trademarks: Microware, OS-9, OS-9/68000,
OS-9000).

Due to its modular design, most of the code is completely hardware independent,
so it can be easily be ported to a different hardware by writing new device
drivers.

The original (1980) OS-9/6809 was designed for the Motorola 6809 processor.
Later (1983) they switched to the 680x0 family and released OS-9/68000.  For
speed and compactness reasons most of the OS-9/68000 kernel is written in 680x0
assembler language.  Now there is a so-called OS-9000 by Microware.  Its kernel
is written in C and thus it is portable.  It is presently available for 680x0
and Intel's 80386/486, and Microware plans to add further support for RISC and
CISC processors.  (C-Kermit has not yet been tested under OS-9000.)

The 100% ROM-able, fast, compact code in conjunction with real-time
capabilities make OS-9/68k ideal for ROM-based systems used in measuring,
controlling, etc.  It has found a wide acceptance within the scientific and
industrial world.

Yet, a full disk based OS-9/68k offers a program development environment
similar to UNIX. This includes (of course, limited) UNIX sofware compatibility
at C source code level, source code level debugging, UNIX I/O model, UNIX task
model, UNIX-like shell and networking.

A number of UNIX utilities like lex, yacc, lint, etc, have been ported to
OS-9/68k.

The basic commands of OS-9 are:

DEL             delete a file
DELDIR          delete a directory
MAKDIR          create a directory
DIR             directory listing
PROCS           show currently running processes
LIST            type contents of a text file
CHD             change working directory
PD              print working directory

All commands can be given a "-?" as a switch, which will display a brief
(usually sufficient) help message.

All command references (like all references to names on OS-9/68k) are NOT case
sensitive (switches, though, may be case sensitive since they are interpreted
by the running program).


1.21.2. OS-9/68K Devices

All devices (terminal lines, networks, disks) can have arbitrary names but the
usual convention is:

Terminal lines:
   term   the console terminal
   t1     terminal line #1
   :
   tn     terminal line #n

Hard disks:
   h0     hard disk #0
   h1     hard disk #1
   :
   hn     harddisk #n

Floppy disks (diskettes):
   d0     floppy disk drive #0
   d1     floppy disk drive #1
   :
   dn     floppy disk drive #n

A path name starting with a slash ("/") must always include a device name as
the first field.  For example, the C-Kermit command SET LINE /T3 would select
the terminal line /t3.

The console terminal is either a real terminal, or the screen and keyboard of a
workstation such as a Macintosh, Amiga, or Atari ST that is running OS-9.
Terminal emulation is not done by OS-9 C-Kermit, but rather by the real
terminal or the workstation console driver.  This includes the capability to
display national and international characters.


1.21.3. The OS-9/68K File System

The file system is tree-structured just like the UNIX file system.

    /h0/chris

means the directory or file "chris" on hard disk #0.

    chris/rubbish

means the subdirectory or file "rubbish" in the subdirectory "chris" of the
current directory.

The command "chd" without any parameters will always take you to your home
directory.

Names of files, directories, devices, and commands are case-independent.
Filenames may contain letters, digits, period, underline, and dollar sign.
They are stored with upper and lower case preserved, but case is not
significant when referring to them.

Wildcard expansion is performed by the shell with two metacharacters:

  * stands for an arbitrary string of arbitrary length ?
    denotes a single character

C-Kermit/OS-9 also expands wildcards itself, using the same notation, for
example:

    C-Kermit>send ck*.\?

(Note: the question mark must be prefixed by "\" to override its normal
function of giving a help message.)

OS-9/68k files are sequential streams of 8-bit bytes, just like in UNIX, except
that carriage return (CR, ASCII 13) is the line terminator, rather than
linefeed (LF, ASCII 10).  Binary files are simply streams of arbitrary 8-bit
bytes.  The OS-9 operating system and utilities are "8-bit clean", so text
files can use any ASCII-based character set that is compatible with your
display and data entry devices, for example ISO 8859-1 Latin Alphabet 1.

Unlike UNIX, OS-9/68k has a built-in method to gain exclusive access to
devices, so no lock files are needed.  The user will be told if the device is
already in use.
1.21.4. To Build C-Kermit for OS-9

Collect all the C-Kermit source files into a directory:

    ckc*.c, ckc*.h, cku*.c, cku*.h, ckwart.c, ckcpro.w, ck9*.*

There are two makefiles: ck9ker.mak and ck9ker.gcc.  If you have a running
version of the GNU C compiler, use ck9ker.gcc (it produces smaller, more
efficient code); otherwise use ck9ker.mak which uses the standard OS-9/68k C
compiler.  Read the appropropriate makefile, edit the necessary changes
mentioned there, create the subdirectories, and make the new Kermit by typing:

    make -f=ck9ker.mak

or:

    make -f=ck9ker.gcc

Read the "beware file" ck9ker.bwr for hints relating to the OS-9 terminal
driver.